DF-2848 smash run (STOCK kernel #0, after fresh vm.sh reset with-src)
======================================================================
Command: kldload /root/poc/gtq_smash.ko   (cnt = MAXCPU + 2048 = 2304)

DragonFly 6.5-DEVELOPMENT #0: Thu Jul  2 06:02:54 UTC 2026     root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC
LOADED=0
ALIVE_30S
gtq_smash: taskqgroup_create(cnt=2304)...
gtq_smash: returned; guest still alive (for now)

Observation: ~48KB written past the struct taskqgroup allocation
(2048 slots x 24B), 2304 taskqueue threads created.  Guest survived
the 30s window: the corruption is SILENT (DragonFly slab allocations
carry no redzones), which is why the deterministic 16-slot readback
proof in run.log is the primary evidence.  No panic was coaxed in the
observation window; impact ceiling is heap-corruption-driven
instability (panic/DoS class) on memory reuse.