The window worker keeps its window over a chunk that doesn't inflate

A live reply cut short (the server's compressed data ending at ".\r\n" at a
read boundary; the spool keeps what Corpus.write refuses) made the worker give
the group back without a snapshot, losing the window and the batch since its
last post (six times in the first 40 minutes on homelab). Now the batch before
the chunk goes out, the chunk is reported (fetched again, plain the second
time) and the range is asked for again from that chunk (RangeOutcome::Again):
the stream waits for the new copy and the window stays. Test: the coordinator
hands the same range back at its resume point after a corrupt report.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

REBUILD.md

@@ -539,7 +539,11 @@ releases, a third of them one poster's image dump (27.7 M rows, LOG.md
    default (`--ranges` keeps the old path). Tests: the lease order,
    takeover and redo, the endpoints with a corpus-served stream and the
    snapshot through the API, the snapshot restoring a window between two
-   ranges (the two-range release one, the album joined).
+   ranges (the two-range release one, the album joined). Deployed and
+   started 2026-10-26 22:37 (LOG.md (118)). A chunk that doesn't inflate
+   (a live reply cut short; the spool doesn't check) is reported after
+   the batch before it went out and the range asked for again from that
+   chunk: the window stays (the first run lost it, and the open batch).
 
 6. **The corpus stays as it is.** Measured on 300 unfiltered chunks
    (30 M lines, LOG.md (102)): 43% of lines lack a "(k/N)" counter, and of