fix(provider-limits): close TOCTOU race in quota recovery clear (I2)

[janeza2]

Summary

Closes the TOCTOU (Time-Of-Check-To-Time-Use) race in the quota-recovery path that was called out as I2 in the review of #6128.

The race

maybeClearRecoveredQuotaState reads a connection snapshot at the start of fetchLiveProviderLimitsWithOptions, fetches quota, then calls clearRecoveredProviderState to clear the transient error state. Between that initial read and the clear UPDATE, a concurrent markAccountUnavailable (from a chat request that just hit a fresh 429) can write a newer error state — which the unconditional clear then overwrites. Result: a just-failed connection flips back to active in the DB, breaking backoff escalation and producing misleading dashboard state.

The fix

• New clearConnectionErrorIfUnchanged(id, expected) primitive in src/lib/db/providers.ts — a single atomic conditional UPDATE keyed on (test_status, last_error_at, rate_limited_until). Returns true if applied, false if a concurrent write changed the row.
• clearRecoveredProviderState now takes an optional expectedState. When provided, it routes through the CAS primitive; when omitted, the existing unconditional path runs (preserves all 13 post-success callers — chat/embeddings/images/etc. — unchanged).
• maybeClearRecoveredQuotaState passes (testStatus, lastErrorAt, rateLimitedUntil) from its in-memory snapshot as the CAS token. last_error_at is the primary signal because markAccountUnavailable always bumps it on every cooldown/error write.

SQLite's single-statement UPDATE is atomic under WAL journaling, so no mutex is needed.

Test plan

New tests in tests/unit/provider-limits-recovery.test.ts:

• CAS primitive clears when expected state matches — direct call to clearConnectionErrorIfUnchanged with matching token returns true and clears the row.
• CAS primitive aborts when state changed concurrently — simulates a concurrent markAccountUnavailable writing fresh state between read and clear; the CAS UPDATE returns false and the fresh state is preserved.
• quota recovery path does NOT overwrite a concurrent mark (TOCTOU closed) — end-to-end: mocks the usage fetch to inject a concurrent DB write mid-fetch, runs fetchAndPersistProviderLimits, asserts the fresh mark survives.

CI runs the full suite (npm run test:unit). Local env couldn't run tsx (no node_modules), relied on ReadLints + visual review of diff. No new lint errors introduced — all reported errors are pre-existing environment issues (@types/node missing, process/unref typing).

Relationship to #6128

This PR branches off fix/quota-cooldown-recovery (the I1 fix). The diff currently shows both I1 + I2 changes against main because #6128 is still open. Once #6128 merges, this PR's diff auto-shrinks to just the I2 incremental changes (the CAS primitive + signature change + caller wiring + 3 new tests).

If preferred, I can also rebase this onto main after #6128 merges.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[diegosouzapw]

Merged — thank you, @janeza2! 🙏 Excellent follow-up: this closes the TOCTOU race (flagged as I2 in the #6128 review) where maybeClearRecoveredQuotaState read a connection snapshot, fetched quota, then cleared the transient state — a concurrent markAccountUnavailable in that window could be silently clobbered. The compare-and-swap primitive (clearConnectionErrorIfUnchanged — a conditional UPDATE keyed on the expected testStatus/lastErrorAt/rateLimitedUntil) makes the clear apply only if the row is unchanged; on a CAS miss it returns the original snapshot and the next read surfaces the fresh state. Clean layering: the CAS lives in db/providers.ts and localDb.ts only re-exports it (Hard Rule #2 ✅). I resolved the merge onto the current release tip — kept your 3 new CAS/TOCTOU tests and the assert.rejects error-only fix from #6128 (the GLM path throws on 429). 8/8 tests green, lint + typecheck clean. Base redirected main→release. Ships in the next release.