fix(regime): reseed stored history on a sensor change, and stop faking an observation

Two review findings on 46ace50.

[P1] Raising HY_OAS_WINDOW_DAYS to 700 only reached newly computed rows. A
routine run recomputes the latest trading date alone, and `rebuilding` was keyed
on "no v3 snapshot exists at all", which is false once the cutover has run --
so every row already written kept the credit gap the wider window exists to
close, indefinitely.

Adds SENSOR_REVISION: stamped into each snapshot, absent on pre-marker rows
(read as 1), and a stored revision below the current one triggers exactly one
reseed. Deliberately not METHODOLOGY, which would partition the history API and
discard the cached event study -- neither warranted, since the study recomputes
its Warning series from source rather than reading snapshots and so cannot be
staled by a reseed.

The reseed is bounded by REBUILD_LOOKBACK_DAYS in calendar days rather than a
session count, because the binding constraint is the OAS fetch: each replayed
row needs W3's 20-business-day lookback inside HY_OAS_WINDOW_DAYS. Replaying by
session count would have left the oldest stored rows unrepaired -- the exact
rows the fix targets. At 672 days the replay covers ~464 sessions, W3's oldest
requirement lands on the first fetched OAS day, and the ~400-session series the
cutover wrote is fully covered. A test asserts that relationship so the two
constants cannot drift back into recreating the gap.

[P2] With nothing ever collected, current_observation returned available=true
and the default placeholders -- "unknown" for every hyperscaler, "mixed" for the
reaction -- so the card announced a reading that never happened. Those are the
absence of an observation, not an observation of absence. Gated on `observed`
(non-null fetched_at, the one field every path writing real content stamps),
which blanks the content and drives a proper empty state naming where an admin
collects one. This was a regression from 46ace50; fundamental_overlay never had
it, since no observation means no effective date means pending.

Also renames the leftover v2 identifiers in the touched paths
(rewrite_existing_v2, latest_v2).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/research/regime-monitor-v3.md

@@ -154,6 +154,14 @@ and refreshing appeared to do nothing. That was the opposite of what this sectio
 already claimed. Showing it early cannot leak into a published number, because
 nothing in the overlay is scored (see "Fundamentals left the score").
 
+`current_observation` gates on `observed` (a non-null `fetched_at`, the one field
+every path writing real content stamps). Without it, the default override —
+`unknown` for every hyperscaler and `mixed` for the reaction — was reported as a
+live observation with `available: true`, so the card presented placeholders as a
+collected reading. Those are the absence of an observation, not an observation of
+absence. `fundamental_overlay` never had this problem: no observation means no
+effective date, which means `pending`, which already blanks the content.
+
 Each snapshot stores the fixed basket symbols, hash, and freeze date.
 Reconstructed history before that freeze date is retrospective/exploratory.
 
@@ -276,6 +284,27 @@ the widened request, not new upstream history — and it makes the chip a better
 truncation canary, since a 700-day request returning ~1095 days' worth is now
 the visible ceiling.
 
+**Widening the window alone does not repair stored history.** Routine runs
+recompute only the latest trading date, and `rebuilding` was keyed on "no v3
+snapshot exists at all" — which is false once the cutover has run — so every row
+already written would have kept its credit gap indefinitely. `SENSOR_REVISION`
+fixes that: it is stamped into each snapshot, snapshots predating it read as 1,
+and a stored revision below the current one triggers exactly one reseed.
+
+It is deliberately not `METHODOLOGY`. That constant partitions the history API
+and discards the cached event study; neither is warranted here, because the study
+recomputes its Warning series from source (`_warning_series` calls
+`warning_sensor_scores` against freshly fetched prices and OAS) rather than
+reading snapshots, so a reseed cannot stale it.
+
+The reseed is bounded by `REBUILD_LOOKBACK_DAYS` in calendar days rather than a
+session count, because the binding constraint is the OAS fetch: each replayed row
+needs W3's 20-business-day lookback inside `HY_OAS_WINDOW_DAYS`. At 672 days the
+replay reaches ~464 sessions, W3's oldest requirement lands exactly on the first
+fetched OAS day, and the ~400-session series the v3 cutover wrote is fully
+covered. A test asserts that relationship so the two constants cannot drift into
+recreating the gap.
+
 The fix was sequenced deliberately: acting on items 1–3 above bumps
 `METHODOLOGY`, which fires `rebuilding`, which would have baked the credit-less
 rows into the fresh series. Fixing the window afterwards would mean reseeding