DF-4926 baseline (STOCK /boot/kernel/nvmm.ko): two independent race runs,
identical crash site, both fatal (guest down; serial console excerpts).

RUN 1 (driver: 40 unload/reload cycles against the unprivileged racer
storming ~1.1M NVMM_IOC_CAPABILITY/s + ~20k machine create/destroy cycles/s
as uid 1002 testnv, group nvmm):

    login: nvmm: attached, using backend x86-vmx        <- ~40 loads
    nvmm: attached, using backend x86-vmx                  during the race
    ...
    FaStopped at      nvmm_ioctl+0x444:       movq    0x48(%rax),%rax
    db>
    (guest down; vm.sh status => down)

RUN 2 (minimal: racer + the FIRST kldunload):

    login: nvmm: attached, using backend x86-vmx
    FaStopped at      nvmm_ioctl+0x444:       movq    0x48(%rax),%rax
    db>
    (guest down)

Crash mechanics: nvmm_ioctl+0x444 loads a function pointer at offset 0x48
of %rax == nvmm_impl, which nvmm_fini() (nvmm.c:1005-1006) had just set to
NULL while the device was still dispatching ioctls -- the unsynchronized
nmachines check (nvmm_dragonfly.c:369) passed, nvmm_fini() ran
(nvmm_dragonfly.c:372) and destroy_dev() only happened afterwards
(nvmm_dragonfly.c:404).  (The "Fatal trap 12" banner itself was truncated
by the crashing console -- the 'Fa' fragment -- but the faulting RIP,
instruction, and dead guest are recorded on the serial log; two runs, same
PC.)

PATCHED (fix.diff applied to guest /usr/src, module rebuilt, same race):
    40/40 kldunload attempts -> EBUSY (rc=1), 0 successes, NO panic,
    ~36M capability ioctls + 684k machine cycles survived; after the racer
    died (fd closed), the final kldunload returned 0 and the module
    unloaded cleanly.  Guest up throughout (race_driver_fixed.log,
    run_fixed_racer.log).