docs: the v2 baseline holds on a second healthy run

Run 7 ended NO FREEZE within 1100s with the same shape as run 5: the same three
threads, the same ceiling of 13 distinct objects, and not one non-SUCCESS window
in 544 across both runs. The v1 stuck-wait side reported its usual single pair.

Run tally since v2 is three runs and no frozen sample - GAME OVER at ~22 min,
EMULATOR GONE at 810 s, and no freeze in 1100 s.

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

docs/re/mission-freeze-resume-spin.md

@@ -510,3 +510,23 @@ run (342 MB resident here) and `run-canary` only clears it at *launch*; and
 `vm.drop_caches` is not writable in the container (read-only `/proc/sys`), so
 page cache can only be left to the kernel to reclaim. Clearing the stale shm
 files between runs is the one lever available.
+
+
+### The v2 baseline holds on a second healthy run (run 7)
+
+`NO FREEZE within 1100s`, and the same shape as run 5 — so the control is
+measured twice:
+
+| thread | run 5 windows / peak / objects | run 7 windows / peak / objects |
+|---|---|---|
+| `F8000008` (main) | 224 / 1 235 / 13 | 167 / 947 / 13 |
+| `F8000234` | 47 / 919 / 10 | 35 / 830 / 8 |
+| `F800025C` | 41 / 819 / 7 | 28 / 737 / 7 |
+| result | SUCCESS ×314 | SUCCESS ×230 |
+
+Same three threads, same ceiling of **13 distinct objects**, and **not one
+non-SUCCESS window in 544** across both runs. The v1 stuck-wait side reported its
+usual single pair (`BE56BB5C`) and nothing else.
+
+**Run tally since v2: three runs, no frozen sample** — GAME OVER at ~22 min
+(run 5), `EMULATOR GONE` at 810 s (run 6), and no freeze in 1 100 s (run 7).