v2.3.0

Upgrading is a binary swap. No data migration, no re-backfill. On-disk state from 2.0, 2.1 and
2.2 is read as it is.

One theme, from sprint earnest-echidna: everything nuthatch says about itself has to be true.
Fifteen issues, eleven PRs. Most of it is a document being corrected to match the binary. The two
places where the binary was the wrong one come first.

A lost tip is no longer silent

/sql used to fall back to sealed history alone when the hot-tip scan failed, log nothing, and
stamp the answer degraded: false. That scan is fallible for an ordinary redb IO error, an
unreadable hot store, or a row failing partway through, so a caller could receive a complete-looking
aggregate computed over none of the unsealed data.

There is now a tip_unavailable field on the query response, an error! log line where the
scan fails, and a caveat in the admin UI. nuthatch sql reports it on both the local and the API
path.

It is deliberately not folded into degraded_tables. A bad segment reduces one table; a failed
hot scan drops every table's tip at once. Different cause, different remedy, so it gets its own
field rather than one that would have to name every table or none.

Rate-limit hints written as Go durations

parse_retry_hint discarded hints of the form 1m30s, which is exactly what Go's time.Duration
prints. The hints being ignored were therefore the long ones, which are the ones worth honouring.

The skill drift gate checks both directions

It only caught flags the reference named and the binary did not. It now catches the reverse as well,
which is the direction that actually ships wrong documentation to an agent.

CI

• Superseded pull_request runs are cancelled. Push runs on main and sprint/* are not.
• The required check's timeout margin is widened to 45 minutes, and an expiry is now distinguishable
  from a cancel rather than reading as though a human superseded it.

Claims corrected against a running binary

Every one of these was found by running v2.2.0, not by reading source:

• three documented CLI invocations the binary rejects
• the go-live checklist demanded an admin token that neither deploy recipe ships any more
• store_holds_rows was documented read-only and was not
• RFC-0034 still described /explain as unbounded, which #367 had already made false
• a --fail-fast carve-out comment cited a line number a merge had moved
• e2e_reorg.rs still said its case was #[ignore]d and "fails today", after the fix un-ignored it
• the README's per-event column list omitted block_hash and _seq

docs/progress-log.md now carries a standing caveat at the top: it is a dated record and not a
reference, so an invocation in it may not work today. Check anything you intend to run against
nuthatch <command> --help, which is the only current answer there is.

Test coverage landed alongside, for the arms that were deletable with the suite green: the 503
hot-scan refusal on /sql and /explain, a two-table cold fixture so a degraded nest and a
degraded result are distinguishable at all, and the mounts readiness path.

Known, and already filed

• The README's cargo install --git line does not work on rustc 1.97 (#534). rust-toolchain.toml
  pins 1.95 and does not apply to cargo install, which builds in a temp directory, so the
  compile reaches a dbsp ICE and installs nothing. This is not new in 2.3.0. Use the prebuilt
  binary attached to this release, curl -fsSL https://nuthatch-indexer.com/install.sh | sh, or the
  container image at ghcr.io/nightswatchhq/nuthatch:2.3.0.
• /explain still degrades to cold-only in silence at a third call site the fix above did not
  reach (#528).
• Three deadline tests fail under load (#529), so cargo test --lib is red on a busy machine
  and green on a quiet one.