fix: bound provider requests with a 60s timeout (scans can no longer hang)

[New1Direction]

The bug

A scan was hanging until the output tab gave up with Analysis timed out — please try again. (output-tab.js:127, the 90s waitForData deadline). Root cause: every provider fetch() in the AI path had no AbortController/timeout, so a stalled connection froze the serialized scan queue indefinitely — the tab's generic 90s timeout was the only escape, and it surfaced no actionable next step.

The fix

• fetchWithTimeout() wraps all 8 provider fetch sites (callOpenAICompatible, openaiChat, callAnthropicCompatible, callAnthropic, callGemini, callNous, callOpenRouter, callXAI) with a 60s AbortController timeout — generous for slow models, well under the 90s tab deadline.
• New non-retryable timeout error kind (errors.js): a stall falls straight to the next provider in the attempt plan instead of withRetry re-hammering the stuck one (which would've made it worse), and surfaces "{provider} took too long — Retry, or pick a faster provider in Settings" (+ an output-tab hint).
• It can't break errors.test.js — the new kind matches a specific timed out after Ns phrase, so "Failed to fetch" etc. still classify as network.

Also: un-reds CI

The time-flaky maintenance.test.js (which was failing on main since the date rolled over) is fixed by pinning the clock with vi.setSystemTime. So this branch lands on green CI rather than inheriting the pre-existing red.

Test plan

• npx vitest run — 713 passing (was 711/712 with the flake; +1 new timeout-kind test)
• node --check on all 4 edited source files
• Re-scan a repo live and confirm a slow/stalled provider now surfaces a Retry within ~60s instead of the 90s generic timeout

Note

This is the issue the user hit live (the output-tab.js:127 error). Doesn't change the serial-queue throughput (a separate audit finding) — but it kills the indefinite hang failure mode.

🤖 Generated with Claude Code