fix: probe tty fd pollability instead of platform-checking; add CI (Linux + macOS)

[bkrabach]

What

Generalizes the macOS fix from #250 and closes the class of bug that let #247 ship broken.

open_dedicated_tty_input() validated that the tty fd could be opened, but never that it could be polled. On macOS the open succeeds and loop.add_reader() then fails with OSError(EINVAL) — deep inside prompt_toolkit, where it becomes EOFError (ptk >= 3.0.53, silent exit right after the banner) or propagates (<= 3.0.52, REPL error loop). Neither is a graceful fallback; both are a dead CLI.

#250 fixed the macOS instance with a sys.platform == "darwin" branch. That is a hardcoded list of known-bad combinations: FreeBSD/OpenBSD/NetBSD use the same kqueue backend and do not match "darwin".

This replaces the platform check with a probe of the actual property that matters:

• _fd_is_pollable(fd) registers/unregisters the fd on a throwaway selectors.DefaultSelector() — the same object asyncio.SelectorEventLoop builds, and the same register(fd, EVENT_READ) call add_reader() bottoms out in. Faithful proxy, no running loop required, two syscalls.
• Device selection becomes an ordered candidate list — /dev/tty first (the controlling-terminal alias, the device the Linux path is production-validated on), then os.ttyname(0). First candidate that opens and probes pollable wins. Rejected candidates are closed immediately.
• If no candidate qualifies, it logs a warning naming what it tried and returns None — prompt_toolkit's own default, which is the pre-fix: dedicate a non-blocking fd for terminal input to stop TTY-reader event-loop freezes #247 behavior and works. Degraded, visible, and alive rather than silently dead.
• No sys.platform check remains except the win32 early-out (Windows has no /dev/tty and no POSIX Vt100Input at all).

Net effect: macOS and the BSDs self-heal via the probe, Linux keeps the exact device and flags it has today, and any future environment where the fd is openable-but-unpollable falls back to a working prompt instead of a dead one.

Verification — real hardware, both platforms

Driven through the real code path (PromptSession(input=get_dedicated_tty_input()), mirroring main.py:2772-2791) under pty.fork() so the pty is a genuine controlling terminal. macOS 26.6 (Darwin 25.6.0, arm64), Python 3.12.12, prompt_toolkit 3.0.52; Linux aarch64, same ptk.

platform	branch	fd opened	result
Linux	main @ e793151 (#247)	/dev/tty	OK — returned 'hello world'
Linux	main @ 7063fde (#250)	/dev/tty	OK — returned 'hello world'
Linux	this branch	/dev/tty	OK — returned 'hello world'
macOS	main @ e793151 (#247)	/dev/tty	FAIL — OSError 22, REPL error loop every iteration
macOS	main @ 7063fde (#250)	/dev/ttys008	OK — returned 'hello world'
macOS	this branch	/dev/ttys008	OK — returned 'hello world'

Candidate-loop behavior, instrumented on real hardware:

platform	scenario	tried	rejected by probe	using	fd leak	prompt
Linux	normal	/dev/tty	none	/dev/tty	none	OK
macOS	normal	/dev/tty, /dev/ttys008	/dev/tty	/dev/ttys008	none	OK
Linux	all candidates forced unpollable	/dev/tty, /dev/pts/215	both	None → ptk default	none	OK
macOS	all candidates forced unpollable	/dev/tty, /dev/ttys008	both	None → ptk default	none	OK

The last two rows are the point of the change: with every candidate rejected — simulating any future unknown breakage — the CLI still gets a working prompt. Under #247 that same condition was a dead REPL.

CI

This repo had no .github/workflows at all. That is the actual reason #247 reached users: 875 lines through the interactive input path, merged 39 minutes after opening, with ## Known gap: not exercised in a live interactive session in its own body, and no automated gate on any platform.

Adds .github/workflows/ci.yml — matrix over ubuntu-latest + macos-latest × Python 3.11/3.12, uv sync then uv run pytest. The macOS job actually exercises the darwin-gated real-kqueue integration test that has never run anywhere.

15 pre-existing failures (identical on main @ 7063fde, unrelated to tty input: render/streaming, cleanup-event ordering, handler methods, provider commands, session lifecycle, subprocess config) are excluded by explicit per-test --deselect with a named TODO — not --ignore on whole files, not || true. Every other test in those files still runs and a new regression there still fails the build.

Tests

tests/test_dedicated_tty_input.py: probe true/false, candidate fallthrough (the macOS scenario reproduced deterministically on any platform), all-unpollable → None + warning log, repointed test seam stays authoritative, and no-fd-leak assertions on every path.

tests/test_dedicated_tty_input.py tests/test_interactive_chat_tty_teardown.py
  16 passed, 1 skipped

full suite: 15 failed, 1261 passed, 1 skipped, 13 deselected, 1 xfailed
main @ 7063fde:  15 failed, 1259 passed, 1 skipped, 13 deselected, 1 xfailed

Same 15 node IDs before and after. 0 regressions.

Two darwin-specific unit tests from #250 were removed — they asserted the platform-gated mechanism this PR deletes (e.g. "/dev/tty is never attempted"). Their scenarios are covered by the new candidate-fallthrough and all-unpollable tests.

Follow-up to #247 and #250. Thanks to @Joi for the correct macOS diagnosis — this generalizes it.

[bkrabach]

CI green on all four jobs — first CI run this repo has ever had.

job	result
pytest (ubuntu-latest, py3.11)	pass
pytest (ubuntu-latest, py3.12)	pass — 1259 passed, 3 skipped, 28 deselected
pytest (macos-latest, py3.11)	pass
pytest (macos-latest, py3.12)	pass — 1260 passed, 2 skipped, 28 deselected

Note the delta: macOS runs one more test than ubuntu and skips one fewer. That is test_darwin_dedicated_input_attaches_to_real_kqueue_loop — the skipif(sys.platform != "darwin") integration test that opens a real fd, attaches it to a real KqueueSelector event loop, and round-trips a byte. It was added in #250 and, with no CI in the repo, had never executed anywhere. It now runs on every push and PR.