re: run 'grep the corpus for the claim' on this corpus -- four still standing

Applying my own METHOD entry one iteration after writing it found four refuted
statements still asserted unmarked where a reader lands:

  * envelope correlation 'has no resolving power' -- in three places including
    HANDOFF. The port controlled the same estimator on a single track and got
    r=1.0000 at zero offset; the saturation needs CONCURRENT streams sharing
    timing. I agreed to this in a message and never landed it.
  * '8 of 10 three-chunk regions' -- still asserted in HANDOFF in a different
    section from its own correction.
  * 'r9 is a wild pointer, never a guest address' -- still asserted inside the
    kept-for-the-record section.
  * the ALSA channel permutation, stated without scope, when a later capture
    measured the identity and labelling from it put the silent channel on the
    wrong name.

All four marked in place, striking the sentence and pointing forward.

Two lessons added: a 'kept for the record' section still asserts, so labelling
the heading is not enough; and naming a refuted claim keeps it greppable, so the
audit returns its own corrections as hits and every hit needs reading.

The first item is the one worth admitting: I acknowledged that correction in a
message, wrote the entry about corrections that never land, and then did not land
my own for a full iteration.

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

docs/port/HANDOFF.md

@@ -2761,8 +2761,12 @@ packets and `to_xma_riffs` yields **[1 294 336, 1 118 208, 1 171 456]**, all thr
 At −300 the *previous* asset's chunks appear while those three stay stable, so −238
 is a real boundary.
 
-**Disc-wide: 24 / 24 single-chunk regions are fine; 8 of 10 three-chunk regions
-start mid-stream.** The defect is specific to the multichannel case.
+🔴 **"8 of 10 three-chunk regions" is DEAD — see the corrected census above.** That
+audit run was cut short and I read a partial file as complete. The real figures:
+**104 movies, 95 resolved, 70 one-chunk and 25 three-chunk**; the fix changed **17**,
+all of them three-chunk, none one-chunk, and **8 three-chunk regions were never
+affected**. "Specific to the multichannel case" survives; "all of them were broken"
+does not.
 
 🔴 **So your leading chunk is a truncated first stream, not a spurious tail** — in
 `ADV` it is 62 % of ctx0. Any measurement you made *on* it was made on a fragment,
@@ -2837,7 +2841,10 @@ same 0.600 scales bed and voice.
 🔴 **Two instruments failed first and both looked convincing** — worth knowing
 before you try to reproduce it. Envelope correlation returns **0.86–0.95 for every
 stream against every channel**, because all six channels share the dialogue's
-timing; that is no resolving power, not a result. Sample-level correlation returns
+timing; that is no resolving power **in this regime**, not a result. ⚠️ Corrected:
+your own control — r = 1.0000 at zero offset, ±0.08 elsewhere on a single track —
+shows the estimator localises sharply; the saturation needs *concurrent* streams
+sharing timing at zero lag. Do not read the original sentence as a general limit. Sample-level correlation returns
 ≈ 0, because the chunks do not start with the movie.
 
 ⚠️ Reach: levels, not waveforms — three numbers agreeing to 0.5 dB plus a 1:1
@@ -3113,8 +3120,12 @@ exception.
 
 **Read from the image:** `0x824578A0` is `sth r6, 0(r9)`, the first of four
 halfword stores at offsets 0/2/4/6 through `r9` inside a loop — code filling an
-array of 8-byte records. **`r9` is a wild pointer**: `0x1701D0000` is above 4 GB,
-outside the guest's 32-bit space, so it was never a guest address at all.
+array of 8-byte records. ~~**`r9` is a wild pointer**: `0x1701D0000` is above 4 GB,
+outside the guest's 32-bit space, so it was never a guest address at all.~~
+🔴 **That sentence is REFUTED — see the retraction above.** Xenia prints `si_addr`,
+a *host* address; the guest is mapped at `0x100000000`, so `0x1701D0000` is guest
+`0x701D0000`, which is exactly `r9` in the register dump. An ordinary heap address
+on an uncommitted page, not a wild pointer.
 
 **It is a third failure mode**, distinct from the cache-flush crash (`0x82307128`)
 and from the loader stall (which logs *zero* crash dumps) — and unlike the stall it