[JunjoSick]

Summary

Four CI-reliability fixes from the 2026-10-20 triage: one prevents a repeat of the Oct 2–20 outage, and three remove intermittent Windows failures, one of which was a real product bug.

1. ci: pin the Rust toolchain (F10). Every stable job installed dtolnay/rust-toolchain's floating stable while the workflow sets RUSTFLAGS="-D warnings". When Rust 1.99 deprecated a std method, all of CI went red for 18 days without any code change. The six non-MSRV jobs now install the exact version in RUST_TOOLCHAIN (1.99.1) through the master ref the msrv job already pins, so raising it is a deliberate PR. CONTRIBUTING documents running the local gate on that version. msrv stays on 1.88.0.
2. test(llm): decode-bisection fixture (F7). invalid_json_endpoint read each request with one read() and closed right after answering. On Windows, closing a socket with unread input sends RST, which can discard the reply before the client reads it. The decode error under test then becomes a transport error, so there's no bisection ([2, 2] instead of [2, 2, 1, 1]), or the test hangs forever on server.await. The fixture now reads the whole request head, half-closes, and drains (bounded); both tests bound server.await at 30 s.
3. test(audio): oversized-response test (F8). Its one-request server was created outside retry_transient_transport, so every retry hit a closed port, and a 5 s client timeout could expire on a busy machine. The server is now created per attempt, as the ElevenLabs tests already do, with a 60 s client timeout.
4. fix(control): resuming a paused job on Windows. Resume rewrites the worker's control file while the paused worker polls it. atomic_replace used MoveFileExW(MOVEFILE_REPLACE_EXISTING), which fails with ERROR_ACCESS_DENIED whenever another process has the destination open, so bookforge resume intermittently failed with "Access is denied (os error 5)". This was the lifecycle flake cli_pause_during_inflight_qa_request_parks_before_more_finalize_work. std::fs::rename uses POSIX rename semantics on Windows and succeeds in that case. The replace stays atomic and failure-preserving, and std falls back to MoveFileExW where POSIX renames are unsupported. CHANGELOG entry added.

Validation

All on Windows (GNU), Rust 1.99.1 with -D warnings:

• Root cause of (4) shown directly: a standalone probe holds a file open and replaces it. MoveFileExW fails with Access is denied. (os error 5); std::fs::rename succeeds. Same result on Rust 1.88.0 and 1.99.1. A new #[cfg(windows)] regression test does the same through atomic_replace; the 26 control:: tests pass.
• (2): the bisection test passed 30/30 alone and the batch::tests module 10/10, against 26/30 and 4/10 on main before.
• (3): 15/15 alone, and the full bookforge-audio lib passes (123).
• (4): the pause/resume lifecycle test passed 10/10, and the full lifecycle suite passed 56/56.
• (1): every non-MSRV toolchain step resolves to ${{ env.RUST_TOOLCHAIN }}. The diff touches only those steps, and validate-release-security.sh passes.
• The local runs above used the tree before build(deps): bundle dependabot updates #153 #155 #156 #157 #158 #161 (lockfile bumps) merged. This PR's CI covers the combined tree.

During the rebase over #161 I found and fixed a mistake in my own first version of (1): a replace-all had dropped the space after uses: on four steps, which would have made the workflow invalid. That version was never part of an open PR.

🤖 Generated with Claude Code