runtime: pi interactive TUI does not submit on Enter (keypress→submit path); node submits+renders, perry no-ops — pi interactive wall

[proggeramlug]

Interactive-mode wall in the pi TUI (gate 3 follow-on; tracker #6564). Pi's TUI renders and accepts typed input under perry (#6704), but pressing Enter does not submit the message — the typed text stays in the input box and no request is made.

Reproduction (node-vs-perry, decisive)

Binary: perry-compiled secret-tests/pi-target/dist/pi-native-accelon-6704; source bundle pi-bundle.mjs (unminified). Harness scratchpad/pty_drive.py (forkpty + scripted input via PTY_SCRIPT env = JSON [[delay_s,"hex"],...]). fd pre-placed HOME (copy scratchpad/pi-home/.pi/agent/bin/fd). A bogus API key is used deliberately (a valid request would 401 — that's the expected visible result; no real key needed):

cd secret-tests/pi-target/dist
CH=$(mktemp -d); mkdir -p $CH/.pi/agent/bin; cp <fd> $CH/.pi/agent/bin/fd; chmod +x $CH/.pi/agent/bin/fd
export PTY_SCRIPT='[[10.0,"68656c6c6f"],[11.0,"0d"],[20.0,"03"]]'   # type "hello", Enter(CR 0x0d), later Ctrl-C
HOME=$CH ANTHROPIC_API_KEY=sk-ant-bogus python3 <harness> out.raw 22 -- ./pi-native-accelon-6704

• node (node pi-bundle.mjs, same input, type earlier since it renders in <1s): "hello" is submitted (cleared from the input, appears as a user message) and an "Error" (the 401 auth failure) renders.
• perry: "hello" remains in the input box; no submit, no request, no error ever appears.

-p one-shot mode is byte-identical to node (gate 2a — the request/HTTP path itself is fine), so this is specific to the interactive keypress→submit path.

Likely root cause (primary hypothesis)

The Enter/Return keypress (CR 0x0d) isn't triggering pi-tui's message-submit handler under perry. Candidates:

1. Keypress decoding: perry's raw-mode stdin delivery / pi-tui's keypress parser doesn't classify 0x0d (or 0x0a) as the submit key it does under node — a key-event divergence (rhymes with the claude-code input-paint/keypress walls: stdin raw mode, key decoding, emitter/listener wiring).
2. Submit handler fires but the async send never runs (event-loop/microtask/continuation dropped — rhymes with runtime: async catch's mutation of a shared object not visible at state-commit → pi one-shot exits 0 not 1 (GATE 2a rc divergence) — pi wall #10 #6672 write-callback and runtime: pi one-shot (-p) dies with 'Uncaught (in promise) undefined' before first output; node completes full API 401 round-trip — pi wall #8 #6660 async). Less likely given "hello" stays in the input (suggests submit itself didn't fire), but rule it in.
3. A dynamic import in the interactive send path silently rejecting (7 runtime-computed import() sites exist; but the input staying put points earlier than the send).

Suggested diagnosis

Instrument node-vs-perry at three points and find the first divergence: (a) keypress received by pi-tui's input reader (what byte/keyname does perry deliver for Enter?), (b) the submit handler invoked, (c) the request dispatched. Add temporary console.error probes to the unminified bundle around the input/submit handler and recompile (or use a debug-symbols perry build). Determining "does the submit handler fire at all" is the first fork (input-decoding wall vs async-send wall).

Context

Separately, pi's /login OAuth flow hits a runtime-computed dynamic import; that's worked around at the source level via pi's own registerBunOAuthFlows() hook (a 1-line entry tweak — not a perry bug). This issue is the interactive keypress→submit path, which IS a perry divergence.