read-only refresh fallback reports a provider as zero when its parse version is unsatisfiable

[iamtoruk]

Found by upgrade-simulation review of #1078 (reproduced 2/2, deterministic): if a refresh lock is stale/held during the ONE-TIME migration window after a parse-version bump, the read-only fallback serves the session cache as-is — but the bump invalidates every cached session for that provider, so the run reports the provider as ZERO (in the #1078 window: all 51,753 codex calls / $4,713 absent from export; menubar shows stale pre-fix numbers). The next healthy run heals completely (daily cache honestly stamps complete:false / watermarkTrusted:false, nothing permanently lost). The class is PRE-EXISTING, not introduced by #1078 — any parse-version bump has this window (base loses antigravity the same way). Hardening: the read-only fallback should refuse to report a provider whose parse version it cannot satisfy (serve stale-but-versioned data, or omit the provider with a diagnostic) rather than reporting it as zero. Window: ~90s staleMs; triggers: force quit/OOM/reboot during the first post-upgrade run, or migration re-parse exceeding the 30s lock wait.

[iamtoruk]

Substantially addressed by #1096 + #1097 (merged 9cfa957, b4a53b5): the read-only fallback's worst consequence — a provider reported as zero during the one-time migration window while the app killed and re-killed the parser — is now structurally prevented (no-output watchdog instead of fixed caps, SIGTERM grace so a lock-holding parse exits cleanly, cold-state splash instead of error-retry loops, and per-file partial saves so every attempt converges). The narrow original mechanism (read-only serve reporting a parse-version-unsatisfiable provider as zero rather than omitting it) remains as a hardening nicety — folding it into this close; reopen if a zero-report is observed post-0.9.21.