Lease lanes for the tail, a mixed lease order, coordinator:status, the edge end to end

A group now has two lease lanes (migration 6600): `history` works the ranges the bounds hand out, `tail` the tail
planner's, each with its own holder, window, snapshot and takeover redo, so a thread on the tail never wades
through a group's history and a held group's tail isn't stuck behind it. The edge puts `--tail-threads`
(EDGE_TAIL_THREADS, 1 of 2+ by default) of its threads on the tail lane; the group routes take `?lane=`. The
lease order within a lane alternates the group with the most planned articles and the longest unheld one. The
takeover redo puts back only the lane's ranges the window did after the snapshot, and a group whose last range
is held by a holder gone quiet can be taken over.

`coordinator:status` prints the catalog's room, the ranges by band, the last hour's rates, the held groups with
their snapshots and the phase-2 backlogs. `tests/e2e` runs the real edge-node binary against the node API: the
corpus-fill race, a failed stream and the restart that restores the snapshot, a restart without the snapshot
file, a takeover (STREAM_CHUNK_WAIT_MINUTES is a setting now). CI builds the binary before the tests.

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

REBUILD.md

@@ -573,6 +573,40 @@ releases, a third of them one poster's image dump (27.7 M rows, LOG.md
    open batch before the group goes back, like a stop does, so the
    window's snapshot survives it; only a batch the coordinator refused
    (lease lost, too large) still loses the window.
+   **Two lanes a group (2026-10-27; migration 6600, LOG.md (119)).** A
+   group's ranges in article order through one window meant a thread
+   that leased a group for its tail range first waded through the
+   group's history (older articles come first), and a held history
+   group's tail waited behind days of its ranges; and the bounds that ran
+   the 2016 window alone (0..0, capture only) shut the tail out entirely.
+   Now `group_leases` has a row per group and *lane*: the `history` lane
+   works the ranges the bounds hand out (the windows, the history), the
+   `tail` lane the tail planner's (priority at or below the tail's,
+   whatever the bounds), each with its own holder, window, snapshot
+   (`<group>-tail.gz`) and takeover redo (the lane's ranges only, and
+   only those the window did after the snapshot: leased, done since it,
+   or read past it). The edge puts `--tail-threads` of its threads on the
+   tail lane (EDGE_TAIL_THREADS; 1 of 2 or more by default, which is
+   what homelab's 16 run with), the rest on history; the prefetcher runs ahead of every held
+   cursor. The seam a group is the same one as before, once: where the
+   history lane reaches the first range the tail lane did, it is caught
+   up. **The lease order** within a lane and priority is a mix (the
+   user, 2026-10-27): one lease starts from the group with the most
+   planned articles, the next from the longest unheld one (never held
+   first), alternating on a sequence (`group_lease_turns`), so a big
+   group snapshotted at a stop doesn't wait behind hundreds of small
+   never-held groups and a quiet group's tail is visited all the same.
+   **`coordinator:status`** (`app/services/status.ts`, `--json`) prints
+   the catalog's room against `CATALOG_MAX_NVME_GB`, the ranges by band
+   (tail, raised, each capture window, the history by thousand), the
+   last hour's indexed and stored articles, the spool, the tail backlog,
+   the held groups with their snapshots' age and size, the snapshot
+   files, and the phase-2 backlogs (provisional releases, probe
+   candidates, the pending ladder, the judge's dirty marks). **End to
+   end** (`tests/e2e`, suite `e2e`, CI builds the binary first): the Rust
+   worker against the real node API, database, spool and corpus — the
+   corpus-fill race, a failed stream and the restart that restores the
+   snapshot, a restart whose snapshot file is gone, a takeover.
 
 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