DF-0106 — no live kernel panic was induced on the writedisklabel path.

The missing-guard bug is confirmed in source (sys/kern/subr_disklabel32.c:363-364
calls dkcksum32(dlp) with no d_npartitions > MAXPARTITIONS32 guard, unlike the
read path at :225-226), and dkcksum32 provably executes on the path (the scan
loop at :358-364 evaluates dkcksum32(dlp) at sector offset 0 where the crafted
label's d_magic/d_magic2 both match). On every harness invocation the trigger
returned ESRCH (loop found no valid on-disk label) and the guest stayed up.

Why no panic: the writedisklabel read buffer is a getpbuf_mem buffer whose data
(b_kvabase) lives in a single ~24 MiB contiguous wired region (swapbkva_mem,
sys/vm/vm_pager.c:235). The ~1 MiB dkcksum32 walk stays inside that mapped
region for ~184 of ~190 pbufs and returns nonzero without faulting. The ~6
faulting pbufs sit at the tails of the 16-bucket LIFO free list and are
unreachable from userspace with only 4 vn devices. 400+ iterations (incl.
80-way concurrency + I/O churn) produced zero panics.

The IDENTICAL root-cause panic IS reproduced live via sibling DF-0107, whose
dkcksum32 runs on a kmalloc(404, M_IOCTLOPS) ioctl buffer that reliably lands
near a thread-stack guard page on fresh boots. DF-0107's panic signature:

    panic: vm_fault: fault on stack guard, addr: 0xfffff800ab221000
    cpuid = 1
    --- trap 000000000000000c, rip = ffffffff80694ff7 ---
    l32_setdisklabel() at l32_setdisklabel+0x57 0xffffffff80694ff7
    dsioctl() at dsioctl+0x721 0xffffffff806976f1

(See ../DF-0107/panic.txt for the full, captured signature.)