v4.13.0

Nuthatch 4.13.0 is an engine release: a page taken over a chain of left joins no longer computes every
row first. There is no storage migration and no other change.

A page over left joins reads only the rows it keeps

Burrmill moves to d8f79e4 (#1970, nuthatch-org/burrmill#94).

• An ORDER BY ... LIMIT (or a plain LIMIT up to 10,000 rows) over a chain of left joins now takes
  its rows from the preserved side first, and every other side is narrowed to the keys those rows
  carry. The rewrite stays out of inner joins, filters over joined columns, shared subqueries, NULL-matching
  joins, mark joins and recursive terms.
• Joins build on the narrowed side rather than whichever side merely looked smaller.
• Registering many views no longer rebuilds the name index each time (1,500 views: 31 s to under 1 s).

On the BetSwirl stopgap nest (160,802 bets, cold, 512 MB engine limit, ThinkPad, 20-run p50, 2026-10-07)
the SDK's first bets pages went from 3.0 s to 2.0 s. A deep offset (skip: 150000), a where user
filter, tokens and the single-bet query are within noise of 4.12.0, because nothing in them can be
narrowed. Answers are byte-identical. #1951
records what under 1 s would take.

Gated on Lodestar's data

The release gate ran this build against a copy of the Lodestar allocations nest with 4.12.0 as baseline:
75 of 75 statements answered, none regressed, none differed; p99 2,711 ms against 2,675 ms; peak RSS
1,923 MiB against 1,918 MiB, under the 2,048 MiB budget. Two candidates failed the gate on the way and
were fixed with tests before this one passed.

Compatibility and upgrade

Replace the binary and restart. No re-index. Process RSS on a narrowed page can be up to about 160 MB
higher than on 4.12.0, because the narrowed rows are held outside the engine pool; it stays within the
per-cursor budget on every nest gated.