Read the paired FinalizeSettle with its own parser in BeginSettle

[mayanksharma-eth]

The problem

FinalizeSettle's account layout — "three fixed accounts, then [source_buffer, destination] per push" — was stated in three unlinked places:

1. A meta literal in the builder (From<FinalizeSettle> for Instruction)
2. A slice pattern in FinalizeSettleInput::parse_body
3. Index arithmetic in the program, in push_destinations:

(FINALIZE_FIXED_ACCOUNTS + 1..instruction.num_account_metas())
    .step_by(2)

Change the fixed accounts on one side and the others still compile. Missing the third copy is the dangerous one and it fails silently: BeginSettle would start reading source buffers where it expects destinations, so the check that each order is paid to its own buy_token_account would compare the wrong account.

This is the change anyone adding an account to the settle instructions has to get right — a solver signer for solver authentication, most obviously.

The change

BeginSettle now reads its counterpart through FinalizeSettleInput::parse, the same parser the finalize applies to itself. The parser is already generic over the account type; the only reason the program couldn't use it is that introspection hands out metas one index at a time rather than as a slice, so introspected_accounts collects the addresses and bridges that gap.

Deleted: push_destinations, finalize_pushes, and finalize_push_amounts (its only non-test caller was finalize_pushes).

Both settle builders now emit their fixed metas from a fixed_accounts helper returning [AccountMeta; N], so the count is load-bearing — adding a fixed account without updating N is a compile error rather than something review has to catch. FINALIZE_FIXED_ACCOUNTS is crate-private now; nothing outside the interface needs it.

Behaviour change

BeginSettle now rejects a finalize whose accounts and data disagree, before pulling any funds, instead of leaving it to the finalize.

The transaction failed either way, so the on-chain outcome is unchanged — but the failing instruction index moves from 1 to 0. Three tests asserted on that index, and their comments described the old blind spot explicitly:

This is the account/data disagreement BeginSettle structurally can't see.

It can see it now. Those tests and comments are updated; no test was weakened to accommodate the change.

Cost

3–4% more compute on the settle path, for the collected address slice:

Benchmark	Before	After	Δ
settles_a_single_order	12,285	12,794	+509
settles_multiple_orders	22,679	23,549	+870
pushes_a_single_order	12,267	12,776	+509
finalizes_with_no_pushes	7,043	7,264	+221

Worst case +870 CU on a 23.5k CU settlement. bench-report.json is regenerated.

If that trade isn't wanted, the cheaper fallback keeps most of the benefit: leave the two read paths separate but derive both from the single fixed_accounts array, so the count still can't drift even though the offsets stay duplicated. Happy to switch if you'd prefer that.

Testing

• just test — 298 tests, all passing
• just lint (clippy --deny=warnings), just fmt-check, just doc-dev — clean
• just bench — regenerated, drift check passes

The property test guarding the two routes into the parser is kept and retargeted: introspected_parse_matches_account_parse now asserts that parsing the introspected metas and parsing the runtime AccountViews recover the builder's pushes identically. On the interface side, parser_recovers_builder_pushes replaces the amounts-only cross-check with a full round-trip over all four push fields (source buffer, destination, bump, amount), since the metas and the instruction data are written by separate paths in the builder.

---

Context: this came out of reading the settle path while scoping solver authentication, which DESIGN.md specifies but the program doesn't implement yet — BeginSettle/FinalizeSettle currently take no signer. That's a separate PR; this one is just the layout dedup that it depends on. Happy to open an issue for the rest of what I noticed if that's useful.