[Bug] M4: Busy-spin at 100% CPU on stdin EOF in shell runtime

[fissible]

Source: external review report, 2026-08-24 (severity: Medium)

Problem

src/shell.sh:355:

IFS= read -r -n1 -d '' -t 1 _k || true

and src/shell.sh:479 if [[ -z "$_key" ]]; then treats an empty key as a timeout tick.

When read returns EOF (tty detached, stdin redirected from a closed source, ptyunit harness edge) it returns instantly with _key="", which the loop handles identically to a 1s timeout → tight loop at 100% CPU for as long as /dev/tty stays open.

What it needs

• Distinguish timeout from EOF: read -t returns >128 on timeout; EOF returns 1 with empty result. Check $? rather than only $_key.
• On EOF: quit the loop cleanly (same path as q), non-zero exit code

Validation note (per org standards): fd/EOF behavior must be verified against a real PTY, not reasoned about — write the ptyunit test first and confirm the read return codes on bash 3.2 and 5.x in the Docker matrix.

Tests

• ptyunit: close the slave side mid-loop → process exits within one tick, CPU not pegged

Effort: S
Deps: none
Priority: pre-OSS-launch blocker (one of #41/#42/#43/#44)

[fissible]

Fixed: EOF discriminator in _shellframe_shell_read_key (>128 = timeout, <=128+empty = EOF); runtime quits cleanly and returns 1. Regression test uses a new tests/fixtures/shell-eof.sh (detached stdin, live /dev/tty). Suite: 1527/1527.