Ψ-W3 remediation: fix the verify doc's wrong render source, add missing content checks, soften unverified claims

Corrected the Render-dialog source name the refusal's evidence depends on, added a by-ear content check and a file-size channel proxy, and stopped two comments from overclaiming.

docs/verify-track-scope-multitrack.md

@@ -30,9 +30,15 @@ Read off:
   to ±1 — what you are confirming here is that it landed at all.
 - The REAPER console shows **no** `ReaSampler capture failed:` line.
 - Track `A` is still the only selected track afterwards.
-
-Repeat with a **razor area** on `A` over the same 10–12 s span and no time selection: same
-three readings.
+- **Content, not just length.** Listen to the landed file. `A` and `B` carry *audibly
+  different* content by the project setup above (tone vs. drum loop), so this is a by-ear
+  check, not a null test: the capture must be the tone alone, with **no** drum-loop bleed.
+  Expected: pure tone, matching `A` soloed. Failing: any trace of `B`'s drum loop audible
+  in the file. This is not a tautology check — the SDK header's own `RENDER_SETTINGS` line
+  admits a second reading, `(&(1|2)==0)=master mix`, under which a single-track track
+  capture could render the **whole master mix** (both `A` and `B`) rather than `A` alone;
+  drum-loop bleed here is exactly what that misreading would produce, and this is the
+  cheapest place in the whole doc to catch it.
 
 **This is the byte-identical floor.** If either cell now refuses, the change is wrong —
 the refusal must fire only above one track.
@@ -69,7 +75,10 @@ are believed to produce N files. That has never been observed.
 Drive REAPER's own Render dialog by hand, with the extension out of the loop:
 
 1. Select `A` and `B`.
-2. File → Render. **Source:** *Selected tracks (stems)* — the dialog wording for `&128`.
+2. File → Render. **Source:** *Selected tracks via master* — the dialog wording for `&128`
+   (SDK header ~3041). Do **not** pick *Stems (selected tracks)* — that is `&2`, a
+   different source bit that unambiguously writes one file per track and would confirm
+   nothing about `&128`.
    **Bounds:** *Custom time range*, 10.000 to 12.000 s.
 3. **File name:** a literal stem with **no wildcards at all** — e.g. `stemprobe`. Clear
    `$track` / `$item` / anything else from the pattern; the extension writes exactly one
@@ -122,16 +131,24 @@ the divergence from §2 is deliberate and this cell is what confirms it is real.
 ## 7. Mono collapse — what is and is not reachable
 
 Capture a range on a track whose content is dead-center (a mono source panned center, or
-a duplicated-channel file). Read off:
+a duplicated-channel file), using time selection **10.000 s to 12.000 s** (2.000 s, 96000
+frames at 48000 Hz — the §1 convention, so the resulting file size is exact). The panel has
+no channel-count readout anywhere (`Sample::channelCount` is not drawn by
+`src/shell/panel/panel_render.cpp`), so read the proxy instead:
 
-- The panel card reports **1 channel**.
-- The console shows **no** `the lossless mono collapse ... landed intact, as captured.`
-  line.
+- Check the landed `.wav`'s size on disk (Explorer → Properties, or a directory listing). A
+  successful collapse is the extension's own rebuild — canonical 44-byte header + 96000 ×
+  4 bytes = **384,044 bytes**. A file near double that (~768,044 bytes, plus whatever
+  REAPER's own render adds for `bext`/metadata chunks) means the collapse did not fire —
+  recheck the source is genuinely dead-center before treating this as a defect.
+- The console shows **no** `the lossless mono collapse ... already reached the bank; only
+  the size win from the collapse was lost.` line.
 
 **Not DAW-reachable:** the collapse's *failure* branch. It fires only if the captured file
 cannot be read, or its temporary rewrite cannot be written or renamed, inside the same
 call that just rendered the file — there is no manual way to inject that fault between the
 render and the rename. The branch is covered only at its reporting seam
-(`tests/test_wav_codec.cpp`, `testCollapseOutcomesReportDistinctly`), and its console line
-has never been seen in a running REAPER. If you ever do see it, the capture in question is
-intact and correctly measured — only the size win was lost.
+(`tests/test_wav_codec.cpp`, `testCollapseOutcomeSuffixesAreDistinctStrings`), and its console line
+has never been seen in a running REAPER. If you ever do see it, the render already reached
+the bank — the report only tells you the collapse's size win was lost, not that the bytes
+were verified (see `docs/TODO.md`'s 0-byte-render entry).