DF-0021 — panic signature from the first exploratory run (krealloc to 4 GiB).
This panic is NOT the signed-shift bug itself — it is the per-type ks_limit
check at kern_slaballoc.c:877 firing because the M_POC type had already used
2 GiB and the 4 GiB krealloc request exceeded the limit. It is included here
as context for why the PoC was revised to use alloc+free instead of krealloc.

From dfbsd-qemu/boot.log (first run, before PoC revision):
---
poc: got 2 GiB @ 0xfffff80118940000; now krealloc to 4 GiB
panic: poc_shift: malloc limit exceeded
cpuid = 0
Trace beginning at frame 0xfffff801187ab718
_kmalloc() at _kmalloc+0xb09 0xffffffff806578c9 
_kmalloc() at _kmalloc+0xb09 0xffffffff806578c9 
krealloc() at krealloc+0x80 0xffffffff806587c0 
poc_modev() at poc_modev+0x66 0xffffffff82600066 
module_register_init() at module_register_init+0x49 0xffffffff806232e9 
linker_load_file.part.3() at linker_load_file.part.3+0x1b9 0xffffffff80624619 
Debugger("panic")
Stopped at      Debugger+0x7c:  movb    $0,0xbdaf09(%rip)
db>
---

This ks_limit panic prevented reaching the line-1202 overflow. The revised PoC
exercises lines 1261 and 1432 directly via alloc + kmalloc_usable_size + free.