ci(terminal): run the browser terminal suite on Linux, Windows and real Safari

[zackees]

Fixes #259.

What changed

• Linux CI (linux-x86-terminal-test.yml → _terminal-test.yml): builds the debug fastled, installs esbuild 0.28.0 and Playwright 1.62.0 Chromium + WebKit, runs all 4 cases of tests/frontend/test_terminal.py, and uploads the server log on failure.
• Windows CI (windows-x86-terminal-test.yml): runs the slot-release regression against ConPTY. The interactive test drives a POSIX shell, so this job deselects it rather than skipping it.
• Real Safari (ci/safari_terminal_smoke.py, run by macos-arm-live-test.yml via safaridriver):
  • the four-blocked-writer slot release, driven by Safari's own WebSocket;
  • a typed command rendered in xterm, with a screenshot artifact.
• Test file:
  • Under CI, a missing binary, esbuild, Playwright or psutil fails the run instead of skipping.
  • The blocked-stdin test is platform-neutral: all four slots must come back within 5 s, with no surviving PTY master or blocked program.
  • Windows fixes: UTF-8 file IO, forward-slash imports, and answering ConPTY's cursor query.
  • FASTLED_PLAYWRIGHT_WEBKIT_ENDPOINT attaches WebKit to a Playwright server on hosts that can't install it.
• Docs (docs/interactive-terminal.md):
  • The stale nix-shell gate is replaced by the CI gates and a portable local recipe.
  • The lifecycle text no longer claims a disconnect was seen during a blocked write.
  • Records the phase 4 decisions and the Windows finding.

RED → GREEN evidence

Throwaway commit 7682b49 restored the pre-#258 blocking write. It was pushed, run, and removed from the branch.

Check	RED (blocking write)	GREEN
Linux, blocked stdin, Chromium + WebKit	failed: "leaked terminal slots" (run)	4 passed, 0 skipped (run)
Real Safari 26.6.1	failed: "leaked terminal slots", recoveredMs: None (run)	slots back in 722 ms, SAFARI240 rendered (run)
Windows ConPTY, blocked stdin	passes even with the blocking write (run)	passes (run)

Phase 3 (Windows): no leak exists, so no fix

The issue inferred a Windows slot leak from code: kernal-api has no ConPTY write_available, so it falls back to a blocking WriteFile. Measurement disproved it.

• Probe: a per-call kernal-api test on windows-latest gave the same result with and without a PIPE_NOWAIT bounded write. Over 15 s of continuous 64 KiB writes to a ConPTY whose child never reads, every call returned within 1.2 s (probe: RED evidence for #296 (do not merge) zackees/kernal-api#297, #296).
• Why: conhost keeps draining the input pipe into its console input buffer.
• My earlier RED was wrong: it required 64 MiB within 30 s, which measures throughput, not parking.
• End to end: the fastled-wasm regression passes on Windows both with the fix(terminal): release a session slot when its client disconnects mid-write #258 fix and with the blocking write restored.

So both kernal-api PRs were closed unmerged, and there is no v0.1.12. Acceptance criterion 4 can't be demonstrated RED, because the defect doesn't occur. The Windows job now guards it on every PR.

Phase 4 decisions (in docs/interactive-terminal.md)

• Per-message cap: none beyond the 64 KiB WebSocket limit. The bounded write already slices a message and checks for disconnect between slices.
• Non-blocking scope: only the bounded write (Unix O_NONBLOCK, toggled per call). The reader stays blocking on its own thread.

Local: bash test passes (304 Rust + 45 Python). Python lint is clean. No JSPI flags or code touched.

🤖 Generated with Claude Code