solana-orderbook: report the competition solutions in the order status

[squadgazzz]

Description

The order status endpoint tells the caller which solvers included an order and at what amounts, so the frontend can show them. GET /api/v1/orders/{uid}/status answered the solved, executing and traded statuses with an empty value list, a leftover from before the autopilot persisted competitions (BE-220).

The orderbook now lists every solution of the auction the status reports, worst to best as the EVM orderbook does, with the executed amounts when the solution includes the order and none when it does not. For a traded order that auction is the one that settled the order's latest trade. Otherwise it is the latest auction in which a solution executed the order, where EVM takes the latest auction overall.

Changes

• solved, executing and traded statuses carry the auction's solutions from proposed_solutions and proposed_trade_executions
• Index on proposed_trade_executions (order_uid) for that lookup

How to test

New DB test, updated unit tests.

Related issues

BE-431

[linear-code]

BE-431

[claude]

Claude finished @squadgazzz's task in 4m 6s —— View job

---

Review

Reviewed the DTO conversion, the status handler wiring, and the find_order_solutions query against the solana.* schema and the autopilot's persistence/ranking code. This looks solid.

Verified correct:

• uid DESC matches the intended worst→best-with-winner-last order: the autopilot assigns uid as the index of ranked (winners first, descending score) chained with filtered_out, so descending uid yields ascending score with the winner last (filtered-out solutions lead, same as the EVM enumerated() order).
• The COALESCE auction pick is sound: settlements.auction_id is NOT NULL, so the latest-trade branch is reliable, and it correctly falls back to the latest executing auction when no settlement is indexed yet.
• The LEFT JOIN can't multiply rows (pte PK is (auction_id, solution_uid, order_uid) filtered to one order), and executed_sell/executed_buy are always both-present or both-absent so the .zip() is safe.
• solutions is a lazily-awaited future, so the extra query only runs for the three solution-carrying statuses.
• New index backs both the fallback subquery and the join; trades(order_uid) already exists for the trade lookup.

One thing to fix (not in this diff):

crates/solana-orderbook/openapi.yml:421-425 — the CompetitionOrderStatus description still says the value list is "empty until the autopilot persists competition results", which this PR makes inaccurate. Worth updating so the spec matches the new behavior. Fix this →

Nothing else blocking — nice job keeping it aligned with the EVM endpoint and documenting the intentional divergences (latest trade vs first, latest executing auction vs latest overall) in the description.
· solana-services/be-431-order-status-solutions