re: a freeze with zero refused resumes; and fix the index that caused duplicate work

One new data point on the in-mission freeze. The refuted resume-spin lead rested
on refused resumes being normal -- thousands during gameplay, more in a healthy
run than a frozen one. Today's freeze log contains zero of them across 1147
lines, and the mission still froze at about 267 s with a black screen, against
2447 in an older log. So the warning is not even necessary for a freeze, let
alone sufficient, which closes the lead from the other side.

Also refuted today, before this file was found: the burst of BaseHeap::Release
failures at the end of the short log looks like a freeze signature and is not.
In the longer log the same failures span lines 1044 to 5210 and the log
continues for 2700 lines afterwards; they begin at mission load in both runs and
are routine.

The uncomfortable part is that both were already settled in
mission-freeze-resume-spin.md, as was the 0xbdb59668 address that a previous
iteration rediscovered independently. That is twice in one session that existing
work was redone.

The cause is mechanical rather than forgetfulness. docs/re/INDEX.md listed 20 of
43 notes and none of the recent ones, so searching the index for prior work on
the freeze returned nothing -- the corpus was searched, but the search was
blind. INDEX.md now carries a generated table of every note under docs/re/, 59
entries with title and status, and states outright that it should be searched
before starting an investigation. Regenerating it is a few lines of Python and
should be redone whenever notes are added.

docs/re/BACKLOG.md

@@ -683,6 +683,19 @@ search cannot find a *schedule*.
   freeze is now the highest-value target: fixing it unblocks arrivals, phase
   advance and the OB series at once. ❔ The 4→8→12 OB rise is now unreproduced in
   **3 of 4** runs.
+* ✅🔴 **(2026-08-25) Freeze: one new data point, and the INDEX was the real bug.**
+  ✅ New evidence closing the resume-spin lead from the other side: the 2026-08-25
+  freeze log has **0** `resume was refused` (vs **2447** in an older healthy-ish
+  log) — **a mission can freeze with none at all**, so the warning is not even
+  necessary, let alone sufficient. 🔴 Also refuted today: the `BaseHeap::Release
+  failed` burst is **not** a freeze signature (routine; spans lines 1044–5210 in a
+  log that runs 2 700 lines further). 🔴 **Both were already settled in
+  `mission-freeze-resume-spin.md`, as was `0xbdb59668` — that is twice in one
+  session that existing work was redone.** Cause is mechanical: **`INDEX.md`
+  listed 20 of 43 notes** and none of the recent ones, so searching it returned
+  nothing. ✅ **Fixed: `INDEX.md` now has a generated table of all 59 notes** with
+  title + status and says to search it before starting. Regenerate when notes are
+  added.
 * ~~🚧 BLOCKER: t=210/240 unreachable in one turn~~ — **superseded, see above**;
   it rested on an untested assumption that a turn is one shell call. 595 s shell cap − ~220 s boot (a ~190 s title movie that cannot be
   tapped through) − ~25 s startup = **~350 s observation ≈ 193 game-seconds**.