Add the Solana auction domain types and the open-orders cut

[squadgazzz]

Description

PR06 of the Solana autopilot track, stacked on PR05 (#4711). Adds the auction domain: the solvable order typed over the shared chain vocabulary, the auction the loop fans out, and the cut from database rows.

The open-orders read is deliberately naive (unexpired, signed, not cancelled on chain), demo scope. The incremental fetch, checkpoint buffer, and the filter pipeline belong to the solvable-orders cache (BE-190). An order without an order_pda row counts as open: the PDA only appears on chain at settlement time.

Changes

• auction: Order and Auction over chain_types::solana, with the loop's AuctionInfo and an id-ignoring PartialEq for the dedupe, plus cut assembling an auction from rows
• db: open_orders with the solvability predicates

How to test

New unit tests, plus an ignored DB test for the solvability predicates (run with the #4715 schema applied: cargo nextest run -p autopilot-svm --run-ignored ignored-only). All pass locally.

Related issues

Resolves BE-182.

[linear-code]

BE-182

[claude]

Claude finished @squadgazzz's task in 2m 47s —— View job

---

PR Review

Reviewed the auction domain types and the open-orders cut against the solana.* schema (from #4715). This is a clean, well-scoped PR — the types map faithfully to the DB rows, the id-ignoring PartialEq matches what the loop's dedupe needs (run_loop::Cycle), and the tests cover the conversion edge cases and the solvability predicates.

Verified:

• open_orders predicates match the schema: the "signed" clause mirrors the solana_order_insert_notify trigger's WHEN, and the LEFT JOIN solana.order_pda cancellation logic correctly treats a missing PDA row as open (canonical orders.order_pda column is NOT NULL, so reading it is always safe — the PDA table is what appears at settlement).
• ORDER BY o.uid gives the deterministic ordering the content-based Auction equality relies on.
• to_amount / valid_to conversions and the kind match are exercised by the non-ignored unit test, and the ignored DB test's expected [1, 5] follows from the predicates.

One robustness note posted inline (auction.rs:63): a single unconvertible row aborts the whole cut, dropping every order for that cycle — worth considering skip-and-log, though it may be fine at demo scope.

Nothing blocking.

[claude]

collect::<Result<_>>()? makes a single unconvertible row abort the entire cut, so the whole auction (all other valid orders) is dropped for that cycle. The SQL predicates in open_orders don't guarantee convertibility: sell_amount/buy_amount are numeric(78,0) with no non-negative or <= u64::MAX check, and valid_to is bigint narrowed to u32 here — any row that fails to_amount/try_into (a value wider than u64, negative, or valid_to > u32::MAX) takes down solving for every order in the cycle.

Since these are exactly the defensive conversions the wider DB types force, consider skipping + logging the offending row instead of failing the whole cut, e.g. filter_map the errors with a tracing::warn!. Given the demo scope this may be acceptable, but on-chain SPL amounts being u64 doesn't stop the orderbook/indexer from writing something the loop can't convert.