docs(x265): head-to-head codex-P1/P2 — real helix geometry + total-stream framing

Codex-P1 #740: reproducer now renders through helix's REAL signed_lift (golden-
ratio azimuth, r=√u), not a golden-angle approximation → genuine helix result;
lane-A re-measured on the real-helix scene (40,750 B, 1358.3 bits/frame, 61.27
dB). Codex-P2 #250: relabelled as TOTAL-stream vs TOTAL-stream (x265's bytes are
the whole HEVC output, not its MV payload). Guard test 117/117.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K3RyLEbuNSHxxB3NTTrGki

Author: claude

.claude/plans/x265-sprite-replay-probe-v1.md

@@ -226,20 +226,34 @@ x265's per-block MV search, on the SAME φ-spiral scene. Reproducer:
 public API — `ResidueEncoder::encode_signed` / `Signed360` / azimuth-roundtrip
 decode — not a re-inline; 3 tests, clippy-clean).
 
-| Lane | Bytes | bits/frame | PSNR | Codec |
+**Codex-P1 #740 correction:** the reproducer renders through helix's REAL
+`HemispherePoint::signed_lift(n, total, sign).cartesian()` (golden-RATIO azimuth,
+`r=√u`), NOT a local golden-angle approximation — so the scene IS the geometry
+`Signed360` encodes and this is a genuine helix-motion-code result. Numbers below
+are on that real-helix scene.
+
+| Lane | Bytes | bits/frame | PSNR | What the bytes are |
 |---|---|---|---|---|
-| A — x265 3.5 medium | 43,115 | 1437.2 | 60.94 dB | general block-MV, blind to scene structure |
-| B — our helix `Signed360` | **432** (192 appearance + 240 motion) | 14.4 | **∞ (bit-exact)** | object-motion: 1× 6-byte code / sprite / P-frame |
+| A — x265 3.5 medium | 40,750 | 1358.3 | 61.27 dB | **TOTAL HEVC bitstream** — texture + residuals + modes + headers + MV, all syntax |
+| B — our helix `Signed360` | **432** (192 appearance + 240 motion) | 14.4 | **∞ (bit-exact)** | **TOTAL our-codec stream** — sprite appearance + object-motion (1× 6-byte code / sprite / P-frame) |
+
+**This is a TOTAL-stream vs TOTAL-stream comparison, NOT motion-vs-motion
+(codex-P2 #250).** Lane A's 43,115 B is the *entire* HEVC output — the 432 B does
+**not** replace only x265's MV field, it replaces x265's whole stream, which it
+can only do because it is model-based. Isolating x265's MV-only bits (via `--csv`
+per-frame syntax analysis) to test the "one code replaces the per-block MV field"
+thesis DIRECTLY is a named follow-up, not measured here.
 
 **Verdict: TAUTOLOGICAL-WIN / MODEL-MATCHED LOWER BOUND (KILL did not fire; NOT a
 general-codec win).** Lane B was handed the EXACT generative model of a
 self-generated φ-scene; the ∞ PSNR is the decoder re-running the same generator.
 Legitimately establishes the object-motion amortization's concrete bit-cost — one
 6-byte `Signed360` per sprite per P-frame = 240 B of motion for the whole
-240-frame GOP — replacing x265's entire per-block MV field, bit-exact on
-model-matched content. Does NOT beat x265 in general: arbitrary non-φ-manifold
-motion needs stored residuals (PROBE-SPRITE-REPLAY's [H] gate), the named
-follow-up. Board: lance-graph `E-X265-HEADTOHEAD-1`.
+240-frame GOP — as a TOTAL-stream lower bound on model-matched content. Does NOT
+beat x265 in general: (1) arbitrary non-φ-manifold motion needs stored residuals
+(PROBE-SPRITE-REPLAY's [H] gate); (2) x265's bytes encode actual pixels while
+ours encode model parameters — different things. Board: lance-graph
+`E-X265-HEADTOHEAD-1`.
 
 ## Follow-up probe queued — PROBE-SPLAT-μ-HYDRATION-RHO (the spatial cousin)