fix: stdin handling on suspend/resume - #331

…ation (#858)

## Problem

`resume()` calls `stdin.resume()` then defers listener registration into
a `setImmediate`:

```ts
this.stdin.resume()
this.addExitListeners()
setImmediate(() => {
  while (this.stdin.read() !== null) {}
  this.stdin.on("data", this.stdinListener)
})
```

The stream starts flowing immediately, but `stdinListener` isn't
attached until the next macrotask. Any keystrokes arriving in that gap
are silently lost — which is exactly the window where a user types after
`fg`.

`setupInput()` has a milder variant of the same bug: `resume()` before
`on("data")`.

The drain loop was introduced in #331 to discard stale input from child
process suspension. The placement made it ineffective: `read()` returns
null in flowing mode because data goes through events, not pull. Stale
bytes were only "discarded" by accident — emitted as `data` events with
no listener present.

**Repro:** in the test suite, `mockInput.pressKey()` right after
`renderer.resume()` is silently dropped. The existing tests masked this
by yielding a macrotask (`await new Promise(r => setImmediate(r))`)
before asserting.

## Fix

Reorder `resume()` to: drain → register listener → resume stream:

```ts
while (this.stdin.read() !== null) {}
this.stdin.on("data", this.stdinListener)
this.stdin.resume()
```

The ordering is load-bearing:

1. **Drain first** — `read()` pulls from the internal buffer in paused
mode, discarding stale input (#331's scenario).
2. **Register listener second** — must come after the drain. Adding a
`data` listener can auto-resume a paused Readable, flushing stale bytes
through the listener before the drain runs.
3. **Resume last** — starts flowing mode. New data hits the registered
listener with zero gap.

`setupInput()` just swaps the two lines (no drain needed at init).

## Tests

**Modified:** removed three `setImmediate` yield workarounds (2 in
`renderer.control`, 1 in `renderer.input`). The tests now assert
synchronous delivery — they'd fail if the fix were wrong.

**New (4):**
- "keystrokes received immediately after resume() without yielding" —
core invariant.
- "keystrokes survive multiple rapid suspend/resume cycles" — 5 cycles,
no accumulation.
- "input buffered during suspension is drained on resume" — `push()`
bytes into stdin during suspension, verifies they're discarded. Directly
tests the #331 scenario.
- "suspend/resume does not leak stdin listeners" — 10 cycles,
`listenerCount("data")` stays constant.

## Background

I hit this in 0.1.88 while building a TUI on OpenTUI and patched the
bundled JS. When 0.1.90 shipped, `setupInput()` had its `setImmediate`
removed but the ordering was still wrong, and `resume()` still defers
via `setImmediate`. I've been running a patched build since.

The `setImmediate` + drain pattern was introduced in #770 (building on
#331). The intent was sound — this fix keeps the drain but moves it to
where `read()` actually works.