docs: correct the v0.27.0 backfill claim — prod needs no backfill

The v0.27.0 notes said prod held 4 histograms that would stay empty until a
backfill. That was wrong, and asserted without checking.

Verified: all four recovered files (K440HJCN.3C0H, K557IF1U.8K0H,
T191HVNP.0S0H, T193L0XM.CI0H) are archive-only — none appears in the production
store or the events DB. Re-running stride detection over the prod store's
10,215 histogram binaries under both the old and new code shows 0 files whose
decode changes.

So the partial-final-block fix is forward-looking: it matters for future
ingests of sub-minute histograms with a partial final block, not for anything
already stored.

TOOL_VERSION still moves with the release, so a future backfill run will
regenerate the whole store instead of skipping. Harmless — byte-identical
output for every stored file — but it costs the full ~2 hours on the NAS, so
it should not be started casually.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HgTe8CamXAHcAmaQ6QNcog

CLAUDE.md

@@ -33,8 +33,9 @@ Read this first when picking the project back up.
   (it gates regeneration). ⚠ On the office NAS this takes **~2 hours**
   (~1.5 files/sec vs 85/sec on the dev box — gzip-4 in `sfm/event_hdf5.py`
   against a Synology CPU). Budget it up front.
-  **v0.27.0 owes prod a backfill:** the partial-final-block fix recovers 4
-  histograms that are still empty in the store.
+  **v0.27.0 does NOT owe prod a backfill** — verified: the partial-final-block
+  fix changes 0 of the 10,215 histograms in the prod store (the 4 recovered
+  files are archive-only and were never ingested).
 - **The "offset" hardware fault has its own journal** --
   `docs/offset_investigation.md`. **5 of 45 units (11%)**, and the fault is
   **persistent** — it stays until the geophone is serviced. Detect it with