- The registry becomes an MBR vault. `vote()` ends with `checkNeedMBR()` subroutine: if the instance app account is at or below its minimum balance, it inner-calls the registry's new `requestMBR`, which pays it `mbrTopUp` (new global, 5 A, settable via `setMBRTopUp`). Users never pay vote-record MBR, and instances no longer need hand-funding.

- Post-condition, not a threshold. The AVM updates `min_balance` the instant a box is allocated but enforces the requirement only after each (outer) transaction, so the account may sit underwater mid-execution as long as the top-up lands first. However, MBR do is enforced between intermediate states of a group transaction, so a sibling payment later in the same group would be too late.

Nits: `checkNeedMBR()` could sit in more than one place:
- periodVoteCache is always an overwrite, so the call could go before it
- on a re-vote the record write is an overwrite too, so the call could be skipped

Left plain at the end for clarity; the saving would be a handful of opcodes. What is not flexible is that it must stay after the vote record write - that write is the allocation it repairs.

feat: enforce Abstain as the last topic option

chore: /docs wording

There are TWO arrows out of the committed artifact, not one, and neither was
checked:

    contracts/out/TrelyanInscription.*
        |  algod compile                |  algokit generate client
        v                               v
    bytecode ==? chain              contracts/trelyan_client.py

The client branch matters more than it looks. contracts/trelyan_client.py is an
89 KB generated file stamped "DO NOT MODIFY IT BY HAND", and the LocalNet suite
deploys the committed TEAL and drives it THROUGH that client. CI only ever
consumes it; nothing regenerated it and compared. A contract whose ABI moved
without the client being regenerated would be exercised by a suite talking to
the old interface -- and the suite would pass.

CHECKED WITHOUT RUNNING THE GENERATOR, DELIBERATELY

`algokit generate client` needs algokitgen-py, which would pin this check to a
generator version whose formatting churn is not a finding. It is also, on the
machine this was written on, blocked outright by a Windows Application Control
policy (os error 4551) -- the same policy that currently blocks cargo-deny.

No generator is needed: the client EMBEDS the full spec it was generated from,
in _APP_SPEC_JSON. Comparing that to the committed arc56.json needs nothing but
the two committed files, runs anywhere, and is stable across generator versions.

The comparison is on PARSED JSON rather than bytes, because the client embeds
the spec minified while arc56.json is pretty-printed -- a byte comparison would
fail always and therefore mean nothing.

Failure reporting distinguishes an ABI-method change (names differ; the suite is
testing a different interface) from a signature/struct/metadata change (names
agree), because those read very differently to a reviewer.

VERIFIED

  - clean tree: all five artifacts plus the client in step, exit 0
  - rename a method inside the client's embedded spec: CLIENT DRIFT, exit 1,
    naming both method lists
  - a missing _APP_SPEC_JSON block is reported as "repair the check", not
    silently passed -- if the generator's output shape changes, this check stops
    reading what it thinks it reads, and that is a finding about the check

HIGH. `falcon_det1024_verify_compressed` takes NO pubkey length parameter:
deterministic.c calls falcon_verify(..., pubkey, FALCON_DET1024_PUBKEY_SIZE,
...), so it reads exactly 1793 bytes from that pointer regardless of what the
caller allocated. `sig` and `message` are length-delimited and bounded; pubkey
alone was not.

FalconDet1024.verify() passed pubkey straight through as a bare c_char_p with
no check, so a shorter buffer read up to 1729 bytes past the end. Reachable
from the shipped public API -- trelyan_pq.verify is exported from __init__ --
so a verifier reading a pubkey from an arbitrary box or file could crash, or
compute a verdict partly from unrelated adjacent heap memory.

Proved with a guard page (two pages, only the first committed, payload flush
against the boundary):

  full 1793-byte pubkey -> returns cleanly, reads exactly 1793
  1792-byte pubkey      -> ACCESS VIOLATION at the first byte past the buffer
  64-byte pubkey        -> ACCESS VIOLATION

The one-byte-short case is the one that matters: it is the realistic
truncation. Reaching it needs no valid signature -- junk bytes with the right
two header values get there.

The asymmetry is what marks it an oversight rather than a decision: sign() has
always checked len(privkey) != PRIVKEY_SIZE. verify() checked nothing.

WHY NOTHING CAUGHT IT, which is the part worth keeping:

  * tests/fuzz/fuzz_falcon_verify.cc (C/ASan, 13.8M execs) DOCUMENTS this exact
    invariant and honours it -- it always hands the function a fixed 1793-byte
    buffer, and its comment calls a smaller one "a caller-side over-read -- a
    harness bug, not a finding". Correct, and it means that harness could never
    surface this by construction.
  * tests/fuzz/fuzz_encoding_atheris.py DID feed short pubkeys and asserted
    verify() "must return False, not raise" -- an assertion the code could not
    satisfy, because it crashed instead. That file is referenced by no
    workflow, so it has never run.
  * No test varied pubkey length; the KAT and fuzz suites vary the signature
    only, always with a full-size key.

The invariant was written down in one file, violated in another, and the
harness that would have caught it was never wired up.

Fixed in BOTH copies. contracts/falcon_det1024.py is the one deploy_testnet.py
signs real TestNet inscriptions with, and fixing only the SDK is exactly how
TCE-03's cwd hijack survived its first fix.

Raises rather than returning False, matching sign(): a mis-sized key is a
caller error, not a failed verification, and returning False would let a
truncated key read as "signature invalid". The Atheris harness's contract is
corrected to expect that, with the reason recorded inline.

9 regression tests, none needing the C library so they run everywhere.
Mutation-proved: removing either guard fails all 9. SDK suite 50 -> 59 passed,
19 skipped.

Security impact: closes a memory-safety defect reachable from the public API of
an audit-bound crypto SDK. No protocol, wire-format or on-chain change; the
contract's own ABI already pins committed_pubkey to 1793 bytes, so on-chain
state was never the exposure -- the off-chain verifier path was.

skip-checks: true