v4.0.0

Nuthatch 4.0.0 is the stable line. It is 3.13.3 plus three fixes merged since (#1608, #1610, #1611),
and the major version is a promise about what happens next rather than a claim about what changed:
from here, a 4.x release keeps config, data directories and the HTTP, SQL and MCP surfaces working, as
set out below.

Compatibility and upgrade

Replace the binary and restart. There is no storage migration, configuration change, NID change or
re-index, and existing sealed segments remain readable. Coming from an earlier 3.x, read the
compatibility section of each release in between: 3.13.3's entity checks in particular, which refuse
at start an entity whose expression must fault on every row. Three things change from 3.13.3.

• nuthatch sql and the MCP SQL tool print columns in the query's order, not alphabetically, and a
  /sql response gains a columns array naming them in that order (#1609). Row objects are
  unchanged, and nuthatch sql --json still prints them with sorted keys.
• A backfill whose RPC endpoints cannot serve its history says so (#1607). An endpoint that has pruned
  the range is named, with the remedy: an archive-capable RPC via --rpc or rpc_urls. When every
  endpoint has pruned it, the backfill stops on the first refusal, and one that makes no progress
  stops with its cause. A runtime hosting mounts warns with the same text and keeps retrying.
• The README demo runs nuthatch dev --backfill 300, the last 300 blocks, because the bundled public
  endpoints cannot serve USDC's 20 million blocks of history and the demo indexed nothing (#1607).
  When a backfill from deployment is long, init prints the --backfill form beside the plain one
  and dev logs the span at cold start. Where a cold start begins is unchanged.

The 4.x promise

From 4.0.0 to the last 4.x release:

1. Config keeps working. A nuthatch.toml, mounts.toml or entities.toml that works on a 4.x
   release works on every later 4.x release, with the same meaning.
2. Data directories upgrade drop-in. A later 4.x opens a data directory written by an earlier 4.x
   in place: replace the binary and restart. No re-index, no re-seal, no migration command.
3. The HTTP, SQL and MCP surfaces do not break. No route, response field, generated table or
   column, or MCP tool is removed, renamed or retyped.

Upgrade only. A later 4.x may update the on-disk format as it opens a directory, and an earlier
4.x is not promised to read the result. Copy the data directory before upgrading to keep a way back.

How releases work from here. A released 4.x only ever gets patch releases, and a patch only fixes.
Features wait for the next monthly minor: 4.1, 4.2, and so on. Correctness and security fixes ship
immediately as patches. A correctness fix is not a break even where an answer changes, and where one
has to refuse a config that silently produced wrong data, or a security fix has no compatible form,
the release notes say so and explain why.

Not covered: downgrades; the off-by-default cargo features graph, folds, counter, exex and
shadow-burrmill, which are experimental, absent from the published binaries and images, and may
change in any 4.x release; the SQL dialect's functions, which are DuckDB's; segment hashes across
arrow-rs versions; the admin UI's HTML; and the postgres-store build's internal schema.

The full contract, with what a minor may add and what waits for 5.0, is in
docs/operators.md.