M3.13g: the version-seven ABCI adapter

[kaikisegfault]

Closes #222.

adapter/cometbft spoke only version one, so no consensus engine could drive a
version-seven node. This adds the Go half: a version-seven local application
client, an ABCI bridge over it, the genesis application state that pairs a home
with a ledger version, and -protocol-version on the two binaries that need it.

What differs, and what deliberately does not

Three fields differ on the wire and all three are in the finalized block: the
block identifier after the state root, a receipt of fifty-six octets under a
version field of 7 with its result byte at offset 39, and a result range of
thirty-three rather than eight.

Nothing else does, so ClientV7 embeds Client and declares one method. The
connection, the request-identifier discipline, the terminal latch, the frame
codec, and every request encoder are shared — the same decision ADR 0059 made on
the C++ side, for the same reason. In the bridge, six of the seven ABCI
conversions name no ledger version, so New and NewV7 differ by the codespace
and by whether a finalized block arrives with an identifier.

The replay handshake

ADR 0058 owed this slice an answer. ApplicationV7 refuses a finalize_block
at any height that is not its current plus one — including one it has already
committed — and that refusal is terminal.

The answer turned out to be a fact about the pinned engine rather than a design.
CometBFT v0.39.4's consensus/replay.go, in the one branch where the
application is ahead of the engine's state, loads its own saved
FinalizeBlock response and replays that height against a mock application
built from it; the source says in as many words that it does not want to call
Commit twice for the same block on the real app. Every other branch replays
from appBlockHeight + 1, which is current + 1 at each step because each
replayed block is committed before the next is sent, or refuses at the handshake
without sending a request at all.

So the adapter reconciles nothing. Inventing a reconciliation would have been
worse than useless: answering a repeat honestly means reproducing per-transaction
receipts the stage no longer holds after commit and the store never recorded.
What it adds is a guard that refuses to forward such a request, using a
height taken only from the application's own answers to Info and Commit, so
it can never exceed the height the application would accept and can never refuse
a legitimate block.

Verification

Focused local checks, run before pushing:

• git diff --check main HEAD — clean.
• gofmt -l over every changed and added file — clean.
• go vet ./... and go test ./localapp/ over the whole internal/localapp
  package in a scratch stdlib-only module — passed. The package imports no
  third-party code, so it type-checks and runs without the module cache; the
  bridge and nodeconfig packages import CometBFT and are verified on the hosted
  matrix, as the repository's resource rules require.

Hosted tools/verify.sh across gcc-debug, gcc-sanitizers, clang-debug,
and clang-sanitizers is the required gate for this change, since it touches Go
sources. Results are recorded below when the run reaches a terminal state.

Evidence in the tests

• All thirty-six results a version-seven block can report — three admission
  failures and thirty-three execution results — decoded, with each field checked
  against the receipt that produced it, and eight refusals exercised.
• Both directions of the version mismatch: version seven refuses version
  one's finalized block and version one refuses version seven's, which is what
  makes -protocol-version fail closed rather than misread a block.
• The version-seven client's request read off a real socket pair and compared
  byte for byte against the shared encoder's output.
• The identity event's type, key, index flag, and value; version one must emit
  no event at all.
• The guard driven from both sides of a commit, with the fake counting its own
  calls to prove a committed height never reaches the local application, plus a
  case proving the guard counts nothing itself.
• A home initialized for version seven carrying the version-seven application
  state, and refusing to be re-initialized for version one.

Owed, and recorded in the ADR rather than implied

• The end-to-end run. Nothing here has spoken to a real CometBFT engine.
  Driving version seven through the single-node integration needs the recorded
  blocks' raw inputs, which no accepted vector file carries; only four of the
  five recorded blocks are reachable in any case, since carried.block4 is at
  height 1,152,000.
• The four-validator devnet stays on version one explicitly. Its genesis and
  the -protocol-version its supervisor passes each bridge must be one choice.
• The uptime schedule is still nullptr, so a chain driven through this
  adapter executes correctly and pays nobody.

[kaikisegfault]

Hosted verification

Run 33500977481 on head 142f750 — passed.

Job	Result
Classify and verify change scope	success (full)
Linux x86_64 / gcc-debug	success
Linux x86_64 / gcc-sanitizers	success
Linux x86_64 / clang-debug	success
Linux x86_64 / clang-sanitizers	success
Verification required	success

That is tools/verify.sh in full on each preset: go mod verify, go test ./...
and go vet ./... over every package, all four commands built with cgo disabled,
the C++ suite, and both the single-node and four-validator CometBFT integrations.
The integrations are what prove the version-one path is unchanged by the
localApplication interface change and the nodeconfig.Ensure signature — they
drive real CometBFT, a real bridge, and a real application through commits and a
restart, on the default -protocol-version 1.

No CMake target and no ctest entry changes: the slice is Go and Markdown, so the
suite stays at 152 entries in the debug presets and 160 under clang-sanitizers.