R1 and R2: the settlement that costs a crowd now says so, and no k travels alone

[thiagorochatr]

The two recommendations from @kauenet's review on #5, and the two optional items
that turned out to be cheap. make verify green, 275 tests.

R1 — the below-k_floor timeout settlement is explicit and opt-in

The solvency-vs-anonymity trade stays as it was argued. What changes is that it
can no longer happen quietly.

It has to be asked for. SettleEpoch carries an allow_below_floor flag.
Without it an under-floor batch is refused with its own code —
BelowFloorNotPermitted (26) — rather than settled. The flag is consent, not a
bypass: the timeout still governs, and a batch that has not waited it out is
still refused with CrowdTooSmall (21). Two codes so a rejection says which of
the two gates closed, and a test pins both.

It leaves a mark. A settlement that lands below the floor logs the count it
carried, the floor it missed and the timeout it settled on:

Program log: mirror-pool: settled 1 spend(s) below the pool floor of 4 on the 3600s
timeout; the effective anonymity set of this batch is its size, not the floor

Before this, a solo timeout settlement and a full crowd were the same transaction
shape read two ways — an observer could count accounts, but the floor it fell
short of was not in the transaction at all. It is a log rather than return data
because settlement makes CPIs and each one clears the return-data slot; it is the
program's first log line, and it costs nothing on the crowd path.

The timeout is per pool. Set at init_pool beside k_floor, immutable
afterwards for the same reason, bounded to between a minute and seven days. It
lives in the four bytes state.rs had reserved, and zero means the program's
default — so POOL_VERSION does not move and the pools already deployed, with
notes still unspent in them, keep the behaviour they were created with. Bumping
the version would have made Pool::load refuse every live account.

mirror settle requires --allow-below-floor and stops with an explanation
rather than warning and settling anyway. mirror init-pool takes
--settle-timeout.

Neither half closes the hole, and docs/THREAT_MODEL.md says so: an adversarial
settler will pass the flag, and the mark reports on your anonymity after the
fact. What they buy is that the trade is now deliberate in the tooling and
visible in the ledger, rather than a default that happens to whoever waited
longest.

R2 — no effective-k without its bracket

Quotation holds the point estimate and the bracket together and is the only
thing that renders either. Anonymity has no Display, and a Quotation cannot
be constructed without a Bracket, so every figure carries its range on the same
line:

loss factor rho      0.0955   in 0.0350 .. 0.1136   <- headline, independent of k
effective-k Shannon  5.1548   in 2.9065 .. 9.4259
effective-k min-ent  2.3478   in 1.5962 .. 3.4583
                     ^ point over the 54 resolved; range spans the 29 unresolved
                       read as one class and as 29 singletons

mirror analyze now refuses outright when the resolved members cannot be
bracketed, instead of printing a point estimate with nothing to say how much of
it is the pool and how much is the tracer's budget.

Wherever a nominal k is surfaced, the measured discount travels with it.
mirror tree and every settlement print it. The figures come from
PUBLISHED_HEADLINE, and they are not typed in: a test recomputes ρ, the bracket
and the member counts from data/sample-privacycash-run6.json and fails on
drift, so the sample stays the only place the number lives.

The rule is enforced rather than remembered. tests/no_bare_effective_k.rs
fails if any module formats one of those figures for output by hand. It was
verified to fail by injecting a violation before being relied on.

O2 and O3

O2 — every published signature now carries its finalized slot, read back from
the cluster, and both evidence generators explain the pruning fallback. The slot
went into the generators rather than the .md files, which are overwritten by
each run.

O3 — docs/PROOF.md now cites programs/mirror-pool/tests/vk_drift.rs. That
test already did what the review asked for: it regenerates the key from the
committed seed under the committed Cargo.lock and compares it to the deployed
vk.rs element by element. Nothing pointed a reader at it.

The evidence was retaken, not kept

The devnet program at 8H3cYoiAA9LM36cyPr4UEv38dhHasSu2XPSdiBfyrLEa was upgraded
to this code, so every published capture was produced again against it:
docs/PROOF.md (a fresh pool, five spends settled together with two of them
pool-signed, a real stake delegation, the vault closing on its floor to the
lamport, the same four rejections with the same codes), docs/CROWD.md (six
members, six distinct validators, one transaction) and the docs/USAGE.md
walkthrough.

One byte of instruction data moved the wire sizes and nothing else. 1228 →
1229, 1140 → 1141, 1194 → 1195, 2218 → 2219, 332 → 333. No member ceiling moved:
a spend costs three 32-byte account keys, so a byte was never going to buy or
lose a member. Both numbers are pinned separately for exactly this reason — the
size moving alone means the encoding changed, and the ceiling moving means the
crowd did.

One correction worth stating. The first attempt at reproducing the
lookup-table settlement paid each member's own relay, which makes a member cost
two distinct account locks instead of three, and the batch settled 22 in 1713
bytes. Those numbers are real and they describe a shape nobody should use —
paying the relay hands the payout to the one party who already knows which spend
was yours. Remeasured at three accounts per member it is 20 members, 2219 bytes
legacy, 333 through the table, which is the published claim. docs/USAGE.md now
states the arithmetic that puts the ceiling at 20, so the next reader does not
have to rediscover it.

Thank you for the review — R1 and R2 were both sharper than the code that
prompted them.

[thiagorochatr]

@kauenet — this is the follow-up to your review. R1 and R2 are both in, and O2 and O3 came along with them.

I could not set you as a reviewer from here: my account has read-only access to this repository and the Reviewers field needs push, so a mention is the closest I can get.