flaky: threads_scheduler_recovers_veto_claimed_before_deadline times out its veto-deadline margin on windows-latest

[BunsDev]

What happened

api::tests::threads_scheduler_recovers_veto_claimed_before_deadline fails intermittently (currently ~always) on Rust checks (windows-latest), at crates/coven-cli/src/api.rs:9647:

assertion `left == right` failed
  left: 0
 right: 1

process_due_threads_proposals(home) recovers 0 proposals where the test expects 1.

Evidence it is a pre-existing timing flake, not PR-specific

• Failed on main itself (docs-unrelated commit 2850c53, run 29870185543, job "Rust checks (windows-latest)") with the identical assertion.
• Failed 4 consecutive times on docs-only PR docs: fix broken links and stale harness claims in entry-point docs #453 (runs of 29880203316), whose diff touches only README.md, docs/HARNESS-ADAPTERS.md, docs/index.md.
• Passed on main runs 29878571108 and 29880708709 in the same window — intermittent, load-dependent.

Likely cause

The test stages a proposal with a 2s VetoWindow, then sleeps 2_100 ms and expects the deadline to have passed. A 100 ms margin is routinely eaten by slow windows-latest runners (or second-granularity deadline comparison), so the proposal is not yet "due" when process_due_threads_proposals runs.

The sibling hermeticity work in #442/#444/#445 covers env-mutation flakes; this one is a timing-margin flake in the same test module.

Suggested fix

Widen the margin (e.g. sleep until the store-visible deadline actually passes, or poll process_due_threads_proposals with a bounded retry loop) rather than a fixed 2.1s sleep against a 2.0s window.