Carry auction id in BeginSettle instruction data

[squadgazzz]

Description

A settlement transaction carries no way to tell which off-chain auction it executed, and something off-chain needs to tie the two together. EVM already solves this: the driver appends the auction id to the settle calldata, the contract ignores the trailing bytes, and the off-chain side reads it back off the transaction input.

This puts an auction_id (i64, little-endian) in the BeginSettle instruction data, between the counterpart index and the per-order pull layout. The program never reads it. It is carried only so a settlement can be tied back to its auction off-chain. FinalizeSettle links back to BeginSettle through its counterpart index, so it carries no copy of its own.

Changes

• BeginSettle builder and BeginSettleInput parser carry an auction_id: i64, little-endian, right after finalize_ix_index.
• Updated the wire-format doc and the byte-exact encode/parse tests, plus a new rejects_missing_auction_id test.
• The client BeginSettle wrapper passes the field through.

How to test

Existing tests

[fedgiac]

I'm fine with the change, just some comments.

[fedgiac]

Considering that these tests are about decoding and encoding, I wouldn't use a global constant for all tests but, in the cases where it makes sense, just spell out the actual bytes and only use the placeholder where it doesn't matter.

[squadgazzz]

Makes sense, updated d8c2546

[fedgiac]

Why i64 instead of u64? Will there ever be a time when we want auction ids to be negative?

[tilacog]

I suspect this regards PostgreSQL only supporting signed integers, and I believe we can relax it to an u64 (and deal with signedness validation at the BE side)

[fedgiac]

I won't push much for using u64 if this makes the back-end more complex, in the end this isn't really used by the contract. I just want to be sure this is an intentional decision.

[squadgazzz]

Yeah, this is intentional. The auction id round-trips from the backend, through the instruction and the indexer, and back to the backend, where it's stored as Postgres BIGINT, which is i64 (same as the EVM autopilot's auction_id). The contract never reads it, so matching the backend type end to end avoids an i64/u64 conversion and a signedness check at the boundary, for a value that's never negative in practice. Happy to switch to u64 if we'd rather enforce non-negativity in the type, but that just moves the conversion to the backend for no on-chain gain.