capture: state the bounds tolerance as empirical, refuse unmeasurable renders, keep refused ones for diagnosis

The one-frame bound is not provable for a per-edge renderer; the test now shows where it breaks. Refused renders move out of the bank instead of being deleted, so the DAW experiment has something to read.

src/core/capture/render_window.h

@@ -13,21 +13,21 @@ namespace reasampler::capture {
 // Returns 0 for a non-positive rate or an empty/inverted window.
 //
 // The offline backend compares this against the rendered file's own frame count, so
-// exact-bounds failures surface as a refused capture rather than a wrong file. That
-// REAPER resolves the two edges the same way is UNVERIFIED — a DAW pass decides
-// whether the equality is exact or off by a frame.
+// exact-bounds failures surface as a refused capture rather than a wrong file.
 long long frameCountFor(double startSeconds, double endSeconds, int sampleRate);
 
 // True when a landed render's frame count is consistent with `frameCountFor`'s
-// answer for the same window. Tolerates a one-frame difference, and exactly one:
-// frameCountFor rounds EACH edge, so it sits within a frame of the window's
-// real-valued length (end-start)*rate — and a renderer that floors, ceils or
-// rounds that same length sits within a frame of it too, so two integers derived
-// that way can never be more than one apart. A window whose edges do not land on
-// frame boundaries therefore cannot produce a larger difference; anything larger
-// is a render that printed something other than the window asked for, whatever
-// the alignment. Widening this past one frame retires the exact-bounds invariant
-// rather than relaxing it — do not.
+// answer for the same window. Tolerates a one-frame difference, and exactly one.
+//
+// That bound is EMPIRICAL. It is provable only for renderer models that derive the
+// count from the window's LENGTH (floor/ceil/round of (end-start)*rate) or resolve
+// both edges by the SAME convention; a renderer that resolves the start edge and the
+// end edge by DIFFERENT conventions can legitimately sit TWO frames from this answer
+// (tests/test_render_window.cpp pins both facts). Which model REAPER uses is
+// unverified, so a refusal one or two frames wide may be this gate's fault rather than
+// the render's — the open DAW question in docs/VERIFICATION.md §Capture range and
+// bounds. Widening past one frame retires the exact-bounds invariant rather than
+// relaxing it, and is not a fix to reach for before that question is answered.
 bool renderHonoredBounds(long long expectedFrames, long long actualFrames);
 
 // True when a render bounded by the selected items' own extent