v2.6.1

A fix release. Two faults found by running 2.6.0 against production data rather than by reading it,
one of which will bite anyone who takes up the [[calls]] feature 2.6.0 introduced.

No new capability, no config changes, no data migration. Swap the binary and restart.

A transient RPC failure no longer kills a nest (#651)

The one to upgrade for. On 2.6.0, a single dropped connection during a pinned eth_call ends the
process:

INFO backfilling 87.6% - block 440066152 of 496262427, 1178466 events, 248 ev/s
Error: pinned eth_call batch at block 440200000

Caused by:
    transport error: error sending request for url (...)

That is a real run of ours: eight hours in, at 87.6%, discarded by one blip.

Every RPC fetch on the sealed-history path has had never-give-up retry with capped backoff for
months. The four fetches that arrived with 2.6.0's parity features did not - the tier-3 call batch,
the IPFS document path's block-hash lookup, the tier-3 block-hash lookup, and the top_level_calls
block-bodies fetch. All four now use the same helper as their neighbours.

This matters more than one lost run because [[calls]] implies a long backfill by construction:
--seal-direct is refused while calls are declared, so tier-3 nests run the slower hot-store path and
are exposed for hours at a time. The feature and the fragility shipped together.

If you hit it on 2.6.0, restart rather than re-index. Nests resume from where they stopped; ours
caught up in 17 minutes.

A nest refuses to serve rows a different config produced (#653)

Add an event to a running nest's nuthatch.toml, restart, and 2.6.0 would start, notice it was
already at tip, index nothing, and serve - stamping the new registry_hash onto data the old
configuration produced. Every query then reported provenance under a registry that never ran.

The only visible symptom was a view failing to load, and only if that view happened to reference one
of the new tables. A change touching tables no view references said nothing at all.

A nest now compares the stored data's registry against the configuration and refuses to start when
they differ, naming both hashes and the remedy. blob.rs already did this for packed nests at mount
time; the ordinary dev --dir path did not, so the guarantee held for mounted nests and quietly did
not for the path everyone starts with.

Upgrading an existing nest is unaffected. A store written before this release has no recorded
hash, and refusing those would break every running deployment for a fault they may not have, so the
hash is adopted and a line is logged saying it was recorded rather than verified. If a nest's config
has changed since it was indexed, re-index it.

Known issue, unchanged in this release

A first run on Ethereum mainnet against the default public endpoints is much slower than it should
be, and behind a provider that refuses over-wide ranges with a rate limit rather than a width
complaint it can stall entirely. Tracked in #672,
with a deterministic reproduction. Passing --window sized by nuthatch doctor --rpc <url> avoids
the worst of it in the meantime. Chains other than mainnet are not materially affected.