Tight per-test timeouts flake on the Windows leg under thread contention

[vyncint]

Today — stress.yml turns up a recurring failure on the Windows leg
whose shape is always the same: a test with a sub-second builder timeout
times out with an empty screen, because the child had not written
anything yet. It is not the same test twice, which is what makes it a class
rather than a bug in any one of them.

Two measurements, on different branches and different thread counts:

date	run	shard	tests	iteration
2026-09-10	34527017048	windows-latest, 8 threads	wait_idle_for_overrides_the_builder_default	—
2026-09-16	35101695488	windows-latest, 16 threads	unanswerable_queries_turn_timeouts_into_diagnoses, the_responder_can_be_disabled_and_says_what_went_unanswered, all_unanswered_queries_are_named, wait_frame_timeouts_carry_the_query_note	21/25

The 2026-09-16 diagnostic, which is the whole story in four lines:

query not named in: timed out after 500ms while waiting for the screen predicate to hold
--- screen at timeout ---
size: 80x24  cursor: 0,0
                          ← nothing on the grid at all

The four queries.rs tests assert that a timeout names the query that
went unanswered. They cannot: the child never emitted the --csi 14t or
--csi 6n within the 500ms the builder was given, so there was no query to
name. The assertion is about the diagnosis; what failed is process startup.

Why it is worth fixing — this is the failure mode that teaches people to
ignore a red stress run, and stress.yml is the instrument this repository
relies on for exactly the bugs it is best at finding. A shard that goes red
for contention rather than for a defect costs a re-run every time and
eventually costs the run its credibility.

It is also the only remaining stress failure not attributable to a test
added on 2026-09-16 (those two are fixed in #359, one of them proven
deterministically).

Fix — the honest options, roughly in order of preference:

1. Give the Windows leg a spawn-latency floor: the 500ms in these tests
   is chosen to keep the suite fast, and ConPTY's process startup under
   16-way contention plainly does not fit in it. A platform-aware minimum
   (cfg!(windows) → a larger floor) keeps the test's meaning — the
   timeout still has to name the query — while not asserting a schedule.
2. Wait for the child to be alive and drawing before starting the clock,
   so the deadline covers the behaviour under test and not the spawn.
3. Failing both: #[cfg_attr(windows, ignore = …)] with the measurement
   written into the reason, which is what this repository does elsewhere for
   ConPTY divergences — but that is the weakest option, since the behaviour
   itself is not Windows-specific and would stop being tested there.

Option 1 or 2 keeps the assertion. Option 3 gives it up; prefer it only if
the first two prove not to hold.

Done when

• stress.yml is green on windows-latest at 16 threads across a full
  25-iteration run, more than once.
• Whatever floor or wait is introduced is justified by a measured
  number in a comment, not a guessed one.
• No test stops asserting that a timeout names the query it was blocked
  on.

---

Found while clearing the 2026-09-16 issue backlog; filed separately rather
than folded into #359, which fixes only the two flakes that PR's own author
introduced.

[vyncint]

One measurement to add, from the first stress run on the fix (#361):

The marker-then-deadline split (option 2) holds for the class — three of
the four tests were green on every Windows shard at every thread count.
The fourth, the_responder_can_be_disabled_and_says_what_went_unanswered,
went red on all five Windows shards at iteration 1, which is not
contention. It runs with answer_queries(false), and ConPTY opens every
child with a handshake that includes a DSR 6n and holds the child's
output until it is answered. Responder off → nothing answers → the child's
bytes never reach the grid, so no marker can ever appear:

Timeout { waiting_for: "… the application queried the terminal (^[[6n) and
  received no answer …", timeout: 30s, screen: <empty grid> }

That is also how the test had been passing on Windows: the 500 ms wait
timed out on an empty grid and named ^[[6n — ConPTY's, not the
child's. A coincidence the marker exposed.

So that one test takes option 3 (#[cfg_attr(windows, ignore)]), but for a
reason the issue did not weigh: not that the timing is hard there, but that
the thing under test — the child's query going unanswered because the
responder is off — is unobservable under ConPTY. The other three keep their
Windows coverage. Two more stress runs are going before #361 merges.