DF-5552 — cam_devq reference count is a non-atomic int and cam_devq_release() frees a devq with active I/O after only a warning

File: sys/bus/cam/cam_queue.c:241-257 (cam_devq_reference, cam_devq_release), consumers sys/bus/cam/cam_sim.c:151,185 (cam_sim_release → cam_simq_release, cam_sim_alloc → cam_devq_reference).

• ++devq->refcount / --devq->refcount are plain, non-atomic, and lock-free. Two SIMs sharing one devq (in-tree: cam_sim_alloc(..., queue) with a passed devq — e.g. mpt's cam_sim + phydisk_sim pair) that are concurrently registered/released (kldload/kldunload, driver attach/detach storm, device re-enumeration) can lose an update: the count drops to 0 while a live sim still holds the devq → camq_fini() + kfree(devq) under the scheduler's feet → use-after-free of the alloc/send queue arrays and the devq itself.
• cam_devq_release() at refcount 0 merely kprintfs a warning when alloc_active/send_active are non-zero (cam_queue.c:251-252) and frees anyway — a detach racing in-flight I/O turns the warning into a UAF instead of a refusal.

No PoC built: triggering requires concurrently (de)registering two SIMs that share one devq — a driver-orchestrated state no in-tree path reaches on this guest (virtio/nata each allocate a private devq). Hardening-class: Low severity, analysis-only.

Fix sketch: make the refcount atomic_add_int/atomic_cmpset_int-based (the file's neighbors xpt_release_bus/xpt_release_target/xpt_release_device in cam_xpt.c:4979-5230 already use that pattern), and refuse (or leak with a warning) the final free while alloc_active/send_active != 0.