stdin surface gaps: emitKeypressEvents never fires on cooked/piped stdin; removeAllListeners is a no-op stub; two fd-0 readers race for the process lock #9692

Four adjacent gaps found while root-causing #9676 (PR #9691), each measured against node, none fixed there.

1. readline.emitKeypressEvents(stdin) + on('keypress') never fires on cooked/piped stdin. Node fires; perry emits keypress only in raw mode. Measured 4/4 roles under node, 0/4 under perry, at every GC churn level. This breaks any tool that reads keypresses from a pipe.

2. rl.close() then a late stdin.on('data'): node stays silent, perry delivers. A divergence in the permissive direction (also filed as #9594 — same behaviour, confirming it independently here).

3. removeAllListeners on the stdin object is a no-op stub. Listeners survive a call that should clear them.

4. Two fd-0 readers exist — the runtime's (os_process_streams) and readline's (perry-stdlib) — and both take std::io::stdin()'s process lock. Whichever starts first owns fd 0; the other parks forever. Pre-existing and structural: it is why PR #9691's ref() deliberately starts no reader. Worth resolving properly (one owner, or a shared reader both surfaces subscribe to) before more stdin features land on either side, because every future fix has to reason about which reader is live.

Verification bar for each: node-compared fixture, both cooked and raw modes, piped and PTY inputs (the PTY distinction is load-bearing — PR #9691 found a pipe-based fixture that passed before and after its fix, so a pipe-only test proves nothing here).