capture: refuse the multi-track ranged item render, silence the track's children and receives for it, and gate every exact-bounds capture on its frame count

docs/TODO.md

@@ -445,3 +445,70 @@ today.
 bitmap and confirmed to place the stroke correctly, or it is redesigned to rasterize at
 physical rather than logical resolution once `IPlugViewContentScaleSupport` (or
 equivalent) makes scaling real.
+
+## A multi-track TRACK capture renders one file per track and lands one of them
+
+**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.
+
+**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.
+
+**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).
+
+**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.
+
+**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.
+
+**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.
+
+## A `SelectedItems` recipe replays against whatever items are selected then
+
+**Context (surfaced by Ψ-W1-T1, capture-range-exactness).** `RunRecaptureFromSource`
+rebuilds a `CaptureRequest` from the recorded `CaptureRecipe` and resolves its source
+tracks by GUID. `renderOffline` engages `RenderTrackSelection` only when the recipe's
+source mode is `SelectedTracks`, which is what makes a ranged item capture and a
+track capture replay against their recorded tracks rather than the live selection.
+
+**The wart.** A recipe whose source mode is `SelectedItems` — every pre-fix item-scope
+capture, and every post-fix full-extent one — renders `&32`, which prints whatever
+items happen to be selected when the replay fires. The recorded recipe therefore does
+not fully determine the audio it reproduces, which is what "recapture from source"
+promises.
+
+**Intended fix.** Not proposed. The recipe stores tracks and a range; it carries no
+item GUIDs, so no guard on the shell side can reconstruct the item selection from
+what is recorded. Closing it means widening `CaptureRecipe` (a wire-format change with
+a version rung) or re-sourcing full-extent item captures through the tracks render too,
+which would drag them onto the isolation path for no gain.
+
+**The constraint the fix MUST handle.** Widening the recipe must keep every already-
+persisted recipe readable, and must not make a replay depend on items that no longer
+exist — a deleted source item has to degrade to a stated refusal, not a silent
+substitution.
+
+**Priority / risk.** Pre-existing; not introduced or worsened by the range-exactness
+work. Harmless when the user re-runs a recapture with the same items still selected,
+wrong when they do not.
+
+**Done looks like.** A `SelectedItems` recapture either reproduces its recorded audio
+from the recipe alone, or refuses with a message naming what the recipe cannot pin
+down.