ci: full-test (windows-latest, 22) job timing out at the 15m cap, red-blocking product PRs #869

What's broken

The full test (windows-latest, 22) CI job is chronically running right at its timeout-minutes: 15 wall-clock cap and has now started timing out and failing product-changing PRs — not because of any test failure, but because the job is cancelled mid-run when it exceeds 15 minutes.

On #867 (a test-only PR), the job was cancelled at exactly 15m0s during the "Run unit tests" step. The unit suite itself reported # fail 0 before the job was killed — i.e. the tests pass, the job ran out of time.

Evidence — the leg has been creeping toward the cap for weeks

The full Windows-22 unit suite runs all 656 unit files (the scoped test (windows-latest, 24) lane runs a subset in ~8m and is fine). The full lane's runtime is trending up as the suite grows; the 15m cap is now the binding constraint, so any small variance (runner load, +1 test file) tips it over. This will recur on essentially every product-changing PR until addressed.

Job annotation: The job has exceeded the maximum execution time of 15m0s → The operation was canceled. Step 10 "Run unit tests" conclusion: cancelled.

Why it matters

Required tests fans in this job, so a timeout here red-blocks merge for any PR that triggers the full matrix — even when every test passes. It's a false-negative gate that will block unrelated work.

Proposed fix

1. Stopgap (this issue): raise timeout-minutes on the full test job in .github/workflows/test.yml:268 from 15 to 20, restoring headroom now. (Windows-22 is the slowest lane; macOS/Linux full lanes finish well under 15m, so a per-job bump is sufficient.)
2. Durable follow-up (separate issue): shard/parallelize the Windows full unit run (it executes 656 files in one lane). The runtime trend means a timeout bump only buys time; sharding removes the cliff. Track separately.

Scope

.github/workflows/test.yml only — CI infrastructure, no product code, no user-facing change.

Context

Discovered 2026-06-08 while running the standard pre-PR gates for #867 (runtime-install no-drift tests, issue #57). #867's code is correct and green on macOS, Linux Docker, and the scoped Windows-24 lane; it is blocked solely by this pre-existing timeout cliff.