Two finds close the press path the operator field-tested:
1. The pod's guarded PANIC key reports through the PILOT KEYPAD bank -- the
binary's ONLY panic press binding is keyboardGroup[KeyboardPilot].Add(
mode 0x200000, mech, 0x19) (FUN_004d266c); there is NO buttonGroup[0x3d]
consumer (0x3d is the lamp address). The desktop Panic click now ALSO
lands as a pilot-keypad key (PadRIO::EmitButton -> EmitKeypad), so the
armed-mode binding fires; a healthy press stays a mode-masked no-op,
exactly the pod behaviour.
2. KeypressMessageID resolved to 0x17 via enum-chain arithmetic; the binary
passes LITERAL 0x19 (two mapper ids are unreconstructed). The armed
keypad send arrived at the Mech as msg 0x17 -- no handler, silently
swallowed. Pinned to 0x19 (Mech::EjectPilot's id on the OWNER receiver --
the collision is the design).
Verified headless through the REAL click seam (BT_BTNTEST=61): generators
killed -> panic-arm ON -> screen-click Panic -> [lbe4key] unit 0 mode
0x650421 -> PUNCH-OUT. Also: IsDisabled eject refusals now log; [padkey]/
[lbe4key] seam tracing under BT_PAD_LOG.
Still open (cosmetic): the flashing eject slot on the engineering MFD shows
no graphic -- the streamed page element's pixmap is unreconstructed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
