[QuantumExplorer]

Fixes #108.

Problem

AbortGuard::timeout converts the timeout to an i32 number of milliseconds with expect(), so any FetchOptions::timeout above i32::MAX ms (about 24.8 days), such as Duration::MAX used to mean "no timeout", panics on the first call with timeout: TryFromIntError(PosOverflow). #108 has a reproduction.

Fix

A new timeout_millis clamps the delay to i32::MAX ms. setTimeout's delay is a signed 32-bit number and browsers fire at once for a larger one, so a longer delay cannot be passed through.

Before and after

FetchOptions::timeout	Before	After
2 s	fires after 2 s	unchanged
i32::MAX ms	fires after about 24.8 days	unchanged
Duration::MAX	panics: timeout: TryFromIntError(PosOverflow)	fires after about 24.8 days

Tests

Unit test timeout_is_clamped_to_the_largest_set_timeout_delay in src/abort_guard.rs. I also ran the reproduction from #108, a call with Duration::MAX, which panicked before and succeeds with this change.

cargo fmt --check, cargo clippy --all-targets -- -D warnings, cargo clippy --target wasm32-unknown-unknown -- -D warnings and cargo test are clean, and the browser suite in test-suite/simple passes in headless Chrome 153.

This is one of 14 PRs from the review asked for in #97. They are independent, and all 14 also merge together cleanly; with all of them merged, both browser suites (test-suite/simple and test-suite/gzip) pass.

🤖 Generated with Claude Code