[JunjoSick]

Summary

CI on main has failed every day since Oct 2 (last green run: Oct 1), and every PR is blocked. This PR fixes both causes:

1. Rust 1.99 deprecation. The runners moved from rustc 1.98.1 to 1.99.0 on Oct 2. That release deprecates AtomicUsize::fetch_update in favor of try_update. Because ci.yml sets RUSTFLAGS: "-D warnings" for every job, the two calls in bookforge-llm/src/concurrency.rs stop clippy, test, test (windows-msvc) and corpus from compiling.
2. RustSec advisories. RustSec advisory audit is a required check on main and fails on 12 advisories in Cargo.lock (zip, rustls, quinn-proto). Fixing only (1) would leave this PR unmergeable. Fixing them in the dependabot PRs instead is a deadlock, since those can't pass CI without (1).

Commits

• fix(llm): both call sites go through one private fetch_update helper with a single #[allow(deprecated)]. Orderings and closures are unchanged. The compiler's suggested try_update is not used: it is unstable on the 1.88 MSRV (E0658, reproduced locally), so it would just move the failure to the msrv job.
• fix(audio): removes an unneeded return in the cfg(windows) branch of atomic::replace_file. CI's clippy runs on Linux and never compiles that block, so this only affects a Windows-local -D warnings run. Behavior is unchanged.
• fix(deps) rustls + quinn-proto: lockfile only. rustls 0.23.45 → 0.23.46 (RUSTSEC-2026-0346/0347/0348/0349); quinn-proto 0.11.16 → 0.11.19 (RUSTSEC-2026-0338 through 0342). quinn-proto is only reqwest's optional http3 dependency and isn't compiled, but cargo audit reads every lockfile entry.
• fix(deps) zip 9: zip 8.6.0 → 9.0.5 (RUSTSEC-2026-0367/0368/0369). Those advisories concern extract(), which BookForge never calls, so they weren't reachable here. zip 9.0.5 declares rust-version = "1.88"; its new nix dependency is macOS/BSD-only. Supersedes dependabot build(deps): bump zip from 8.6.0 to 9.0.0 #152.
• fix(deps) rustls-webpki + webpki-roots (added Oct 21): lockfile only. rustls-webpki 0.103.15 → 0.103.16 (RUSTSEC-2026-0382, distrusted intermediates could be accepted) and webpki-roots 1.0.8 → 1.0.10 (RUSTSEC-2026-0381, distrusted emSign intermediates). Both advisories were published on Oct 19–20, after this PR's audit first passed, and the stacked fix(validation): stop untranslated prose hiding behind reference context #160 failed the audit on them. Both releases are within the 1.88 MSRV; cargo audit --deny warnings passes again.

zip 9: what changed in behavior

• Entry names. ZipFile::name() and ZipArchive::file_names() now return ZipResult<Cow<str>>, so 6 call sites in bookforge-epub and one test changed. zip 9 decodes names lazily: UTF-8 first, then CP437, which maps every byte. So no name that 8.6 accepted is now rejected. The only difference: an entry flagged UTF-8 that contains invalid bytes decodes as CP437 instead of lossy UTF-8; such an entry is invalid EPUB either way. validate.rs keeps its existing skip-unreadable-entry behavior. New test: a non-ASCII entry name (capítulo-東京.xhtml) resolves through inspect, read and rebuild.
• Zip-bomb defense (stricter, review this one). zip 9 itself refuses to inflate an entry past its declared uncompressed size. A lying entry is now rejected at declared size + 1 byte, earlier than BookForge's per-entry limit used to catch it. But zip reports this as a bare InvalidData I/O error with no entry name. ArchiveReadBudget::read_entry now re-raises InvalidData read errors as EPUB decompression failed for '<entry>': …, matching its other limit errors and the module's promise to name failing entries. Genuine I/O errors are still passed through unchanged. Three tests changed:
  • The two "lying declared size" tests still require rejection and the entry name; they now expect the real reason (declared size exceeded) instead of the per-entry-limit message, which would no longer be true.
  • The running-total test built its scenario from lying entries, which zip 9 now refuses to read at all. It now uses honest 48 KiB entries with a directly constructed ArchiveReadBudget, so the read-time running total is still exercised.

No CHANGELOG entry, consistent with #145/#146/#148; the zip-bomb change is internal hardening with no user-facing option. Happy to add one if you'd like it recorded.

Validation

Run on Windows (GNU) with CI's exact compiler, rustc 1.99.1, and RUSTFLAGS="-D warnings", following the steps of scripts/verify.sh:

• cargo audit --deny warnings (the required check's command): 0 advisories, exit 0
• cargo clippy --workspace --all-targets --all-features --locked -- -D warnings: pass
• cargo +1.88.0 check --workspace --all-targets --locked (MSRV): pass
• cargo fmt --all --check, git diff --check, scripts/validate-release-security.sh, cargo check -p bookforge-cli --no-default-features, dashboard runtime.test.cjs: pass
• cargo test --workspace --locked: 1,426 passed, 1 failed, 9 ignored; --examples: 13 passed; bookforge-epub alone: 165 passed. The one failure was cli_pause_during_inflight_qa_request_parks_before_more_finalize_work with Access is denied. (os error 5), a Windows file-sharing race between the paused and resumed processes, unrelated to zip. It passed in both earlier gate runs of this branch, 8/8 run alone, and in two full runs of the lifecycle binary (56/56 each).
• Not run locally: the browser smoke step (no Playwright/Chromium here), Linux, and Windows MSVC. CI covers those. The previous push of this branch passed clippy, test, test (windows-msvc), msrv, fmt, corpus (small) and CodeQL on GitHub; only the audit failed.

Known flaky test, unrelated to this PR. batch::tests::persistent_decode_error_bisects_an_oversized_batch_after_retry fails intermittently on Windows with request counts [2, 2] instead of [2, 2, 1, 1], and can hang, because server.await has no timeout. Batch execution uses the limiter touched in the first commit, so I compared under identical conditions (same toolchain, flags and machine):

Code	single test ×30 (ok/hang/fail)	batch::tests module ×10
main (before)	26 / 1 / 3	4 / 3 / 3 (a second batch of 8: 6 / 1 / 1)
this branch	29 / 1 / 0	9 / 0 / 1

These are small samples. They show no regression, not an improvement. The flake needs its own fix.

After merge

Rebase the remaining dependabot PRs (#153, #155, #156, #157, #158). #152 is superseded by this PR, and dependabot should close it once main has zip 9.

🤖 Generated with Claude Code