Unsynchronized dmat->segments allocation and map_count bookkeeping race under concurrent map create/destroy (double allocation leak; tag UAF window)

Summary

Lazy dmat->segments alloc with NULL-check but no lock (double-allocate+leak); map_count check-vs-increment window spans blocking M_INTWAIT kmallocs - tag_destroy's EBUSY can pass while another CPU is inside map_create -> tag UAF in sloppy drivers (detach racing open). Needs a racing driver harness; narrow window. Eager-alloc + atomic/spin-protected fix.