test(check order): differential revert-order harness for B20 multi-precondition ops

[amiecorso]

Summary

Follow-up from PR #89 (audit response). Adds a differential check-order test harness covering every multi-precondition function in the B20 surface. The harness pins the canonical first-firing revert selector for each pair of preconditions a function enforces, so that any future drift between the Solidity reference and the Rust precompile surfaces as a precise selector diff in fork mode.

Canonical order = Solidity reference (Option A from the audit-response report). Tests pass in mock mode iff Solidity follows canonical (it does, by construction), and they pass in fork mode iff Rust agrees with canonical. The five fork-mode failures in this PR are intentional and surface real Rust↔Solidity divergences — no Rust changes here; this PR exists to highlight the divergences and lock them in as regression coverage.

Coverage

Exhaustive across the B20 surface — covers every multi-precondition function. PR #91 (BOP-196) merging into this branch unblocked the final revokeRole pair.

File	Pairs	Mock	Fork
test/unit/B20/supply/mint_revertOrder.t.sol	10	10/10	8/10
test/unit/B20/supply/burn_revertOrder.t.sol	3	3/3	3/3
test/unit/B20/supply/burnBlocked_revertOrder.t.sol	6	6/6	5/6
test/unit/B20/supply/updateSupplyCap_revertOrder.t.sol	1	1/1	1/1
test/unit/B20/erc20/transfer_revertOrder.t.sol	15	15/15	14/15
test/unit/B20/erc20/transferFrom_revertOrder.t.sol	3	3/3	2/3
test/unit/B20/erc20/approve_revertOrder.t.sol	1	1/1	1/1
test/unit/B20/permit/permit_revertOrder.t.sol	1	1/1	1/1
test/unit/B20/policy/updatePolicy_revertOrder.t.sol	3	3/3	3/3
test/unit/B20/roles/revokeRole_revertOrder.t.sol	1	1/1	1/1
test/unit/B20/roles/renounceRole_revertOrder.t.sol	1	1/1	1/1
test/unit/B20/roles/renounceLastAdmin_revertOrder.t.sol	1	1/1	1/1
test/unit/B20Security/batch/batchBurn_revertOrder.t.sol	7	7/7	7/7
test/unit/B20Security/batch/batchMint_revertOrder.t.sol	2	2/2	2/2
test/unit/B20Security/redeem/redeem_revertOrder.t.sol	6	6/6	6/6
test/unit/B20Security/identifiers/updateSecurityIdentifier_revertOrder.t.sol	1	1/1	1/1
test/unit/B20Security/announcement/announce_revertOrder.t.sol	4	4/4	4/4
test/unit/B20Factory/createB20_revertOrder.t.sol	2	2/2	2/2
Total	68	68/68	63/68

Full mock-only suite passes with no regressions to existing tests.

Rust↔Solidity divergences surfaced

The five fork-mode failures are the actual check-order divergences between the Rust precompile (base@f9d9d2804) and the Solidity reference. Each is a precise selector diff at a specific multi-violation input:

Function	Pair	Solidity (canonical)	Rust (actual)
mint	role vs zeroRecipient	AccessControlUnauthorizedAccount	InvalidReceiver(0)
mint	pause vs policy	ContractPaused(MINT)	PolicyForbids(MINT_RECEIVER, ...)
transfer	zeroReceiver vs zeroSender	InvalidReceiver(0)	InvalidSender(0)
burnBlocked	pause vs blocked	ContractPaused(BURN)	AccountNotBlocked(...)
transferFrom	allowance vs executorPolicy	InsufficientAllowance	PolicyForbids(EXECUTOR, ...)

These five are now structural facts of the codebase. The PR's value is making them visible and pinning them so:

• Future Solidity refactors that drift the canonical order surface as new mock-mode failures
• Future Rust refactors that align with canonical flip the failing tests to passing — no manual reconciliation needed

Each divergence has a tracking ticket under the Internal Audit Fixes milestone (see the thread on #proj-b20).

Design notes

• Pair coverage is enumerative, not sampled. For each function with N preconditions, there are C(N, 2) pairs. The harness writes one test per pair, asserting the canonical first-firing selector. Some pairs are unreachable (mutually exclusive violations) and are explicitly skipped with a note in the file's natspec.
• Composed functions don't re-test their base. transferFrom only adds tests for its two new preconditions (ALLOWANCE, EXECUTOR-POLICY); the underlying _transfer body pairs are already pinned by transfer_revertOrder.t.sol. Similarly batchMint only pins LENGTH/EMPTY against the first per-element check (ROLE), since the rest of _mint's order is pinned by mint_revertOrder.t.sol.
• vm.prank pattern. Tests that need a role-resolution view call (e.g. security().BURN_FROM_ROLE()) resolve it to a local variable BEFORE the vm.prank, to avoid the prank being consumed by the view call. Same pattern as _setRedeemPolicy in B20SecurityTest.

Out of scope

• No Rust changes. The 5 divergences are real and require a coordinated decision before fixing one side or the other. This PR captures them; the alignment work is a separate effort (tickets queued under Internal Audit Fixes).
• No Solidity behavior changes. All Solidity check orders are unchanged; the harness only adds tests asserting the current behavior.
• Storage cleanup (auditor's D2). Out of scope; was not a real divergence (see PR #89).

Commits

• 68d763d test(check-order): differential mint revert-ordering harness
• e337e92 test(check-order): extend revert-order harness across all multi-precondition ops
• 5a827f1 test(check-order): extend harness to roles, admin ops, announce, and createB20
• 03cefcd style: forge fmt
• d7e49ca test(check-order): revokeRole pair test (unblocked by BOP-196 merge)

[linear]

BOP-198

BOP-199

BOP-202

BOP-200

BOP-201