ci: hunt flakes on Windows too, where the exit edge is synthesized

[vyncint]

The stress workflow ran on Linux and macOS only, which left the leg that became required in 0.10 as the least exercised — and it is the one whose liveness the harness manufactures rather than reads.

On Unix "the terminal closed" is a kernel fact: EOF on the master means every slave descriptor is closed. On Windows the pseudoconsole's output pipe outlives the child, so EXIT_CLOSES_THE_TERMINAL + ExitWatch synthesize the edge — reap the child, drain for DRAIN_GRACE (500 ms), call it closed. Polling plus a grace window is the shape a one-in-N flake lives in, and nothing had run it more than once per commit. The other Windows-only path is common::fixture_bin, which shells out to cargo build -p from inside the tests, on the one filesystem that refuses to relink a running .exe.

Three things this is not:

• Not a blind matrix add. windows-latest defaults to pwsh and the iteration loop is POSIX shell, so the job pins defaults.run.shell: bash. Git Bash ships seq and arithmetic expansion, so one script still serves all three; on Unix the only change is an unused pipefail.
• Not the same clock. A Windows iteration costs two to three times a Linux one and the serial shard is the long pole, so Windows gets 60 minutes against 30 — a timeout that fires on a healthy run is a false alarm that costs more than the minutes it saves.
• Not the same faults at the ends of the thread axis, and the comment now says so: at 1 thread Windows hunts the exit synthesis rather than the macOS teardown race, at 16 it hunts conhost churn on a four-core box.

The 94 #[cfg_attr(windows, ignore)] tests stay ignored — that is what ConPTY cannot honour, not what is untested. README and CONTRIBUTING §3 now name the third OS.

Proof, not just intent: a real 20-iteration dispatch of the new workflow ran against this branch before merge — https://github.com/vyncint/termlens/actions/runs/34200079944

Closes #290

[vyncint]

Dispatch results — the leg works, and it immediately earned its keep.

Two real dispatches of the new workflow against this branch:

run	iterations	Windows shards	outcome
34200079944	20	5/5 green	found a queries.rs flake on macOS @4 threads
34201210388	40	5/5 green	found a frames.rs flake on macOS @1 thread

Neither flake is Windows and neither is caused by this change — both are pre-existing macOS timing faults that a deeper loop surfaced, which is the entire point of the workflow.

• Fixed here (second commit): a_query_the_app_moved_past_is_context_not_a_cause spent one 400 ms budget on both a wait that must succeed and a wait that must expire, with a deliberate 200 ms fixture sleep in between. Root-caused, fixed by moving the short deadline onto the wait that needs it, and hammered 40× locally at 8 threads with zero failures.
• Filed, not guessed at: A resize event goes missing on macOS: the app never acknowledges the SIGWINCH and wait_frame runs out its deadline #292 — a resize notification going missing on macOS so form-echo never acknowledges the SIGWINCH (last: empty, "1 complete frame in total" after 10 s). That is not the frame-cursor gap this test was originally written for, it did not reproduce in 30 local Linux runs, and widening a deadline would suppress it rather than fix it. It deserves its own investigation and does not block this change.

Sizing, now measured rather than estimated: 40 iterations cost ~10 min per Windows shard, so a full 100 extrapolates to ~25 min plus the ~6 min prebuild — comfortably inside the 60 minutes this PR gives Windows, with room for a slow runner day.