Refuse every multi-track selected-tracks render, both scopes; make a failed mono collapse observable

docs/TODO.md

@@ -511,39 +511,40 @@ registration and `ingestHandleSectionCommand` move into it and gain unit coverag
 `ingest.cpp`'s own `command_id`+`gaccel` registration collapses onto
 `action_registry::registerAction` where the shapes match.
 
-## A multi-track TRACK capture renders one file per track and lands one of them
+## The `&128` multi-track output shape is still DAW-unobserved, and a refusal now rests on it
 
-**Context (surfaced by Ψ-W1-T1, capture-range-exactness).** Track scope has always
-rendered through `RENDER_SETTINGS &128` ("selected tracks via master"), and the
-ranged item capture now joins it there. The SDK header (~3041) documents the
-single-file bit `&(4<<16)` for "rendering selected items or razor edits" only, so it
-does not apply to `&128`: the reading is that N selected tracks produce N files.
-`capture.cpp` sets `RENDER_PATTERN` to one literal stem and detects success by
-`std::filesystem::exists`, so N stems collapse onto one name and whichever file
-survives lands as a successful capture carrying one track's audio.
+**Context.** The multi-track TRACK capture no longer lands one track's audio under an
+`Ok`: `renderOffline` refuses every selected-tracks render covering more than one track,
+both scopes, naming the way out (`render_settings::isMultiTrackStemRender` /
+`multiTrackRefusalMessage`). What did NOT change is the evidence: the per-track-output
+reading of `&128` is still INFERRED from the SDK header documenting the single-file bit
+`&(4<<16)` for item/razor sources only. It has never been observed in a DAW.
 
-**The wart.** `renderOffline` refuses this shape for the ranged ITEM capture
-(`render_settings::isMultiTrackRangedItemRender`) because that path was newly routed
-into it. Track scope with two or more tracks selected has the same exposure and is
-deliberately untouched — changing a shipped action from "produces a file" to
-"refuses" is a behavioral-contract change, and it was out of that track's surface.
+**The wart.** The refusal is therefore as unverified as the defect it closes. If REAPER
+in fact sums a multi-track `&128` render into the single literal `RENDER_PATTERN`, the
+refusal costs a working capture — a user who selects two tracks and captures gets a
+message where a correct summed file used to land.
 
-**Intended fix.** Not proposed. Three shapes exist and the choice is a product call,
-not a mechanical one: refuse (matching the item path), render each track and land N
-bank entries (that is batch capture's meaning, not this action's), or sum the
-selected tracks into one file (needs a summing render source `&128` does not offer).
+**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.
 
-**The constraint the fix MUST handle.** The per-track-output reading of `&128` is
-INFERRED from the header's single-file wording, never observed in a DAW. Verify it
-first — including what REAPER actually writes when N stems share one literal
-`RENDER_PATTERN` — because the answer decides whether this is a defect at all.
+**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
+from a fresh capture), and must not re-open the collapse for any caller that reaches
+`&128` later — the predicate is keyed on the render source precisely so new callers
+inherit it.
 
-**Priority / risk.** Unknown until the DAW check above runs. If the reading is right,
-a silently-wrong capture on an ordinary two-track selection; if wrong, nothing.
+**Priority / risk.** Low and bounded either way: the current behavior refuses rather than
+lands wrong audio, so the cost of being wrong here is a refused capture, not a bad one.
 
-**Done looks like.** The `&128` multi-track output shape is DAW-confirmed, and track
-scope either produces defined correct output for a multi-track selection or refuses
-it with a message naming the reason.
+**Done looks like.** The `&128` multi-track output shape is DAW-observed and written into
+`src/shell/capture/CLAUDE.md` as fact rather than inference, and the refusal is either
+kept as-is or narrowed to the item scope with that observation cited.
 
 ## A `SelectedItems` recipe replays against whatever items are selected then