Ψ-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/TODO.md

@@ -527,11 +527,16 @@ message where a correct summed file used to land.
 
 **Intended fix.** Run the observation in `docs/verify-track-scope-multitrack.md` §3 (a
 hand-driven Render dialog, source "selected tracks via master", one literal filename, two
-tracks selected — then count the files REAPER writes). If it comes back "one summed
-file", the refusal is over-strict for the TRACK scope and should be narrowed back; the
-ITEM-scope half stays regardless, since a per-item-track render is not the sum the user
-asked for either way. If it comes back "one file per track", nothing to do and the
-inference is retired into fact.
+tracks selected — then count the files REAPER writes). If it comes back "one file per
+track", nothing to do and the inference is retired into fact. If it comes back "one
+summed file", the refusal is over-strict for the TRACK scope and should be narrowed back
+— and the ITEM-scope half is then an OPEN question, not settled: a full-extent item
+capture already sums a multi-track item selection via `&32|single-file`
+(`tests/test_render_settings.cpp:262`), so if `&128` also sums, a ranged item capture
+routed through it sums too, and keeping the item refusal in that branch would make item
+scope inconsistent with itself across the range boundary (full-extent sums, ranged
+refuses, same scope). Whether that inconsistency is acceptable or the item refusal should
+narrow too needs its own look at that point — not decided here.
 
 **The constraint the fix MUST handle.** Narrowing the refusal must keep the ITEM scope
 refusing, must keep `renderOffline` the single seam (so a recipe replay cannot diverge
@@ -645,3 +650,20 @@ stereo file today.
 **Done looks like.** A dead-center instrument bake lands as a 1-channel file with
 `Sample::channelCount` matching, the same way an offline dead-center capture does; a
 true-stereo bake is byte-identical to today's output.
+
+## A 0-byte render can pass every gate and land as `Ok` (pre-existing, not a Ψ-W3 regression)
+
+**Context (surfaced by Ψ-W3 review).** `OfflineRenderBackend::capture`'s exists-check
+(`capture.cpp:489`) passes for a 0-byte file, and the bounds gate (`:507-546`) only fires
+when `expectedFrames > 0` — an invalid/empty layout reads `expectedFrames == 0` and skips
+the gate rather than refusing. A 0-byte render can therefore reach `stampCaptureSample`
+and land as `CaptureStatus::Ok` with an empty `contentHash` and `channelCount == 0`.
+
+**Not introduced by Ψ-W3.** The exists-check and the `expectedFrames > 0` guard both
+predate this track; Ψ-W3 only added the mono-collapse failure report that sits downstream
+of this hole and was careful not to assert bytes it never verified (see
+`reportCollapseFailure` in `capture.cpp`).
+
+**Intended fix.** After the exists-check, also reject a 0-byte file explicitly (its own
+status, not folded into `BoundsMismatch`, since a 0-byte file was never bounds-checked at
+all) before anything downstream reads it.