Observed pre-empting kernel failures on the same race surface during PoC
development (all on the UNPATCHED kernel). These corroborate known filed
findings; they are NOT the DF-5037 deadlock itself.

## 1. DF-4474 leak fed to the per-malloc-type limit (run at 07:19, 07:27, 07:36)

kHz-rate table churn whose reloads mostly FAILED (ENOENT from the ctor path
below) leaked the inbound prop tree on dm_table_load_ioctl's error returns
(known DF-4474: unreleased prop_array_iterator retains the whole inbound
cmd_data tree). Every malloc type has ks_limit = min(RAM,KVA)/10
(sys/kern/kern_slaballoc.c:371-372; guest has 4 GB -> ~390 MB), so the leak
panics the guest in ~16-100 s of churn:

    panic: prop dictionary: malloc limit exceeded
    _kmalloc() at _kmalloc+0xb09
    _prop_dictionary_expand() at _prop_dictionary_expand+0x31
    prop_dictionary_set() at prop_dictionary_set+0x3cc
    _prop_dictionary_internalize_continue() ... / _udev_dict_set_cstr() at +0x36
    Debugger("panic")

(The allocation site varies; the accounting is what kills it.)

## 2. devfs sysref_get-on-PUTAWAY assertion in the vn_open path (run at 07:25)

Thread A inside dm_pdev_insert's vn_open(nlookup phase) racing thread B's
destroy_dev of the same dm node:

    panic: assertion "(sr->flags & SRF_PUTAWAY) == 0" failed in sysref_get at sys/sys/sysref2.h:70
    reference_dev() at reference_dev+0xa9
    v_associate_rdev() at v_associate_rdev+0x31
    devfs_allocv() at devfs_allocv+0x1a0
    devfs_vop_nresolve() at devfs_vop_nresolve+0x185
    vop_nresolve() at vop_nresolve+0x53
    Debugger("panic")

Manifestation of the known dm_dev remove-lifecycle race family
(DF-2443/DF-2447) plus devfs teardown TOCTOU.

## 3. devstat_remove_entry NULL deref from the remove hammer (run at 07:42)

    Fatal trap 12: page fault while in kernel mode
    fault virtual address = 0x0
    Stopped at devstat_remove_entry+0x25: movq (%rdx),%rax
    (current process = the remover)

Blind remove-hammering vs recreate tripped the known DF-2443/DF-2447
dm_dev_remove no-ref-held UAF class; fixed in the PoC by serializing
remove/recreate.

## 4. Environmental discovery (not a filed bug, context for reproducers)

A dm device's devfs node returns ENXIO on open until the device has been
RESUMED at least once: dm_dev_resume_ioctl -> dmsetdiskinfo() initializes the
disk media info (d_media_blksize); before that the disk layer rejects opens.
dm-on-dm tables therefore only stack onto devices that were created AND
load+resume'd (this is what `dmsetup create --table` does implicitly). A
raw-ioctl reproducer must replicate the create+load+resume sequence for the
backing dm device or every stacked dm_pdev_insert vn_open fails ENXIO ->
linear ctor returns ENOENT (which then feeds failure #1 above at high rate).