fix(scripts): make smoke:tui assert the TUI survives its first frame (#2147)

`smoke:tui` spawned the launcher with `stdio: ["ignore", …]`, waited for
"MCP Servers" in the output, printed OK, and SIGTERMed. It never looked at
the child again.

The child was already dead. Ink mounts `useInput`, `useInput` needs raw
mode, and raw mode is a property of the file descriptor — with stdin on
/dev/null the TUI painted one frame and exited 1 about 40ms later with
"Raw mode is not supported on the current process.stdin". Measured here:
first frame at 396ms, exit 1 at 433ms. The smoke won that race and
reported success, so what it asserted was *first paint*, not survival —
contradicting its own header ("boots and renders without crashing").

This is not environment-specific: `stdio: ["ignore", …]` makes the child's
stdin /dev/null whether or not the developer's terminal is a TTY, so this
smoke has never verified a running TUI on any machine. And the race cut
both ways — an `exit` processed first failed the run, which reads as flake
rather than as the standing defect.

Two pieces:

- `scripts/lib/pty.mjs` gives the child a real terminal via `script(1)`,
  no dependency. The three flavors are not interchangeable (BSD takes
  argv; util-linux takes one shell string plus `-e`; busybox that string
  without `-e`), so the invocation is built and unit-tested rather than
  written inline. A platform with no `script(1)` skips loudly instead of
  running without one, which would be a guaranteed failure rather than a
  weaker check.

- `scripts/lib/render-smoke.mjs` is the fix: the child must still be
  running `surviveMs` (default 2s) after first paint. Without that, a
  future harness change reintroduces the same false green and nothing
  notices — which is why it lives in a module `test:scripts` drives
  against a stub that paints the marker and immediately exits. Today's
  harness passes that stub; this one fails it, with a diagnostic that
  distinguishes "died after painting" from "died before painting".

The smoke additionally fails if the raw-mode error appears in a passing
run, so a future Ink that degrades to a warning instead of throwing can't
ship a TUI with no keyboard input past this gate.

Verified end to end: with a `script` shim that allocates no pty, the smoke
now fails with "it painted one frame, it did not run"; with the real one
the TUI is still running 2s after its first frame and never logs the
raw-mode error.

The `process.env.CI` skip stays, but its comment is corrected: the PTY
removes the technical blocker it used to cite, so the smoke is local-only
by decision now, not by capability. Whether it joins GitHub CI is out of
scope here (#2146 is keeping the other local-only smokes out on purpose).

Signed-off-by: Cliff Hall <cliff@futurescale.com>
Signed-off-by: cliffhall <cliff@futurescale.com>

clients/launcher/README.md

@@ -87,10 +87,18 @@ through the built launcher artifact (beyond the `--help` checks in
   resolution paths (default-catalog seed-on-missing, read-only `--config`
   error-without-seed, `--catalog`/`--config` conflict).
 - `npm run smoke:tui` (`scripts/smoke-tui.mjs`) — launches
-  `mcp-inspector --tui --catalog <temp>` and asserts the Ink app renders its
-  first frame within a timeout, then shuts it down (a shallow boot/render
+  `mcp-inspector --tui --catalog <temp>` **under a pseudoterminal**, asserts the
+  Ink app renders its first frame within a timeout, then waits and asserts it is
+  **still running** before shutting it down (a shallow boot/render/survival
   check, not full interaction).
 
+  The second half is the assertion (#2147). Spawned with its stdin on
+  `/dev/null`, Ink cannot enter raw mode for `useInput`, so the TUI painted one
+  frame and exited 1 about 40ms later — and this smoke, which settled OK on the
+  first frame, won that race and reported success on every machine. It is
+  local-only (self-skips under `CI`), which is precisely where a false green
+  goes unnoticed.
+
 Both build `test-servers/build` on demand if it is missing.
 
 ## Development