docs: record the millisecond floor as located and closed, and split what stayed open

The retired custom-bounds premise is corrected wherever it was encoded: the tail
bit is the time selection's, not custom bounds'.

docs/product/capture-tail.md

@@ -53,12 +53,20 @@ snapshot/restore, forces dither and all normalize-postprocessing off, and render
 32-bit float. The tail wires into that existing path — no new render trigger, no
 new backend.
 
-### Bounds are always custom — so the tail bit is always `&1`
+### Bounds are always the time selection — so the tail bit is always `&4`
 
-The backend renders with `RENDER_BOUNDSFLAG = 0` (custom time bounds) for **every**
-scope and every range type: it sets `RENDER_STARTPOS` / `RENDER_ENDPOS` explicitly
-from the request's exact seconds (`capture.cpp` ~L352–354). It does **not** use the
-time-selection / selected-items / regions bounds modes.
+The backend renders with `RENDER_BOUNDSFLAG = 2` (time selection) for **every**
+scope and every range type: it writes the request's exact seconds into the
+project's own time selection via `GetSet_LoopTimeRange` (`capture.cpp` ~L470–477;
+`RENDER_STARTPOS`/`RENDER_ENDPOS` are also written, as a defensive no-op for a
+mode-0-only field, but the window itself travels in the time selection). It does
+**not** use the custom-time-bounds mode (`RENDER_BOUNDSFLAG = 0`) — that mode was
+tried and retired: DAW observation showed REAPER resolving a custom-bounds window
+on a whole-millisecond grid AT RENDER TIME, flooring the end and rendering exactly
+the floored frame count, which silently broke the exact-bounds precision
+invariant. The time-selection mode does not floor the window. (The one narrative
+home for that finding is `render_settings.h`'s `kRenderBoundsTimeSelection`; this
+doc points there rather than retelling it.)
 
 `RENDER_TAILFLAG` is a bitmask keyed to the **bounds mode**, not the capture range
 type (header line 3047):
@@ -69,18 +77,20 @@ RENDER_TAILFLAG : &1=custom time bounds, &2=entire project, &4=time selection,
                   &32=selected project markers/regions
 ```
 
-Because we always render in custom-time-bounds mode, **the only tail bit that ever
-applies is `&1`**. There is no per-range-type tail-flag decision to make — a razor
-capture, a time-selection capture, and an item capture are all custom-bounds
-renders under the hood, so all three take `RENDER_TAILFLAG = 1`.
+Because we always render in time-selection mode, **the only tail bit that ever
+applies is `&4`**. There is no per-range-type tail-flag decision to make — a razor
+capture, a time-selection capture, and an item capture are all time-selection-bounds
+renders under the hood, so all three take `RENDER_TAILFLAG = 4`.
 
 > **Correction to the framing brief.** The brief asked us to pick a
 > `RENDER_TAILFLAG` bit *per capture range type* (time selection vs. razor vs. item)
 > and flagged `&32` as "markers/regions." The header (line 3047) says `&32` =
 > *selected project regions* and `&8` = *all markers/regions* — but neither matters:
-> our renders are all `RENDER_BOUNDSFLAG = 0`, so the tail bit is `&1` unconditionally.
-> The existing `kTailFlagCustomBounds = 1.0` constant in `capture.cpp` (~L80) is
-> already correct; the field wiring is what's missing.
+> our renders are all `RENDER_BOUNDSFLAG = 2`, so the tail bit is `&4` unconditionally.
+> The existing `kTailFlagTimeSelection = 4` constant in
+> `src/core/capture/render_settings.h` (the bounds mode's own bit, per bounds mode —
+> header line 3047) is already correct — it was right from the start; the wording
+> above it (which had assumed a custom-bounds render) was what was wrong.
 
 ### Mode 1 — Automatic (default): generous tail + auto-trim to -72 dB
 
@@ -88,7 +98,7 @@ Set, in addition to the exact `STARTPOS`/`ENDPOS` already driven:
 
 | Setting | Value | Meaning / header ref |
 |---|---|---|
-| `RENDER_TAILFLAG` | `1` | apply tail for custom time bounds (line 3047, `&1`) |
+| `RENDER_TAILFLAG` | `4` | apply tail for time selection (line 3047, `&4`) |
 | `RENDER_TAILMS` | `8000` | the 8 s cap, in ms (line 3048) |
 | `RENDER_NORMALIZE` | `32768` | **only** the trim-ending-silence bit (line 3051, `&32768`) |
 | `RENDER_TRIMEND` | `≈ 0.000251` | -72 dB threshold (line 3062; scaling below) |
@@ -156,7 +166,7 @@ The existing (currently unwired) `CaptureRequest.renderTail` / `tailMs` fields
 
 | Setting | Value |
 |---|---|
-| `RENDER_TAILFLAG` | `1` |
+| `RENDER_TAILFLAG` | `4` |
 | `RENDER_TAILMS` | `request.tailMs` (clamped to the 8 s cap — see below) |
 | `RENDER_NORMALIZE` | `262144` (`kNormalizeDisableAll`, unchanged) |
 | `RENDER_TRIMEND` | not set / irrelevant (trim bit is clear) |
@@ -177,9 +187,9 @@ adds a third state, so the wiring is a small enum, not a bool:
 - **None** (default for null-test / verify captures, and the current two-scope
   action defaults): `RENDER_TAILFLAG = 0`, `RENDER_TAILMS = 0`, normalize =
   disable-all. Exact bounds. Byte-identical to today.
-- **Auto** (the new user-facing default for tail-on captures): tailFlag `1`,
+- **Auto** (the new user-facing default for tail-on captures): tailFlag `4`,
   tailMs `8000`, normalize `32768` (surgical trim), trimEnd `0.00025119`.
-- **Manual(ms)**: tailFlag `1`, tailMs `clamp(ms, 8000)`, normalize `262144`
+- **Manual(ms)**: tailFlag `4`, tailMs `clamp(ms, 8000)`, normalize `262144`
   (disable-all), no trim.
 
 Recommended shape: replace `bool renderTail` with a `TailMode { None, Auto,