v5.6.3

Nuthatch 5.6.3 makes the SQL memo hold what it counts. There is no storage migration.

The memo counted a seventh of what it held

The /sql memo charges each remembered answer against its 64 MB ceiling (NUTHATCH_SQL_MEMO_BYTES).
It charged the rows as serialized JSON but kept them as one JSON value per row, every column name
allocated again in every row, and it kept the path of every sealed segment the answer read without
charging for any of it (#2072). On a copy of the production allocations nest, 4,818 segments, a memo
reporting 56 MB held about 410 MB of heap.

An entry now keeps its rows serialized and a digest of the segment stamps instead of the list, and is
charged for the table names, provenance and watermarks it keeps beside them (#2073). The same replay
holds 56 to 61 MB for 56 MB counted. A remembered answer is written straight into the response, so
its body is the computed one byte for byte, cached aside, and a hit no longer serializes the rows
again.

Gated on Lodestar's data

The memo is on the /sql path the release gate measures. Run on the ThinkPad against the allocations
nest copy and its 75 recorded statements, with a 5.6.2 baseline from the same box: PASS, all 75
answers identical to 5.6.2's, none slower past the bounds (p99 2,779 ms against 2,733 ms), peak RSS
1,380 MiB against 5.6.2's 1,428 MiB under the 2,048 MiB budget. The gate starts a fresh server for
each pass, so it measures the computed path and the memo's charging, not repeated hits.

Compatibility and upgrade

Replace the binary and restart. A 5.6.2 store is used as it is, and the memo starts empty as always.