solana-autopilot: release the orders of a winner skipped before dispatch

[squadgazzz]

Description

Stacked on #4987.

When a winning solution has a sponsored order whose creation can't be countersigned, the executor skips the winner without sending anything to the driver. By then the competition is persisted, and the skip comes before the settlement window opens. So the in-flight hold treats the skipped winner like a settlement that might still land and keeps all of its orders out of the cut until the deadline plus ~150 slots.

That hurts in two ways:

• Healthy orders batched with a dead creation sit out for about a minute.
• A transient RPC error at the countersign parks the solution long enough for its pending creations to die for real.

The hold already lets go of a solution whose window closed as rejected, which means no transaction went out. A skip is the same situation, so the executor records the skipped winner as a window that is rejected from the start. The orders held out with settlements in flight debug log lists the uids too.

This needs #4987. Without it, a released dead order re-enters the auction, wins again, and sinks its batch every cycle until its stored deadline passes.

Before, a skipped winner held its orders like a real settlement. Now they are back in the next cut.

Changes

• A winner skipped before dispatch gets a settlement window closed as rejected, which the in-flight hold already releases
• The held-out debug log lists the order uids

How to test

New DB test.

Related issues

BE-335

[linear-code]

BE-335

FE-695

[claude]

Claude finished @squadgazzz's task in 1m 55s —— View job

---

Review

I read the diff against origin/solana-autopilot/be-334-drop-dead-sponsored-creations and traced the surrounding code (executor.rs, db.rs, observation.rs, provider.rs).

• Read the diff
• Analyze changed files in context
• Post inline comments for any issues
• Post summary

Verdict: looks correct — no blocking issues found.

The change is clean and consistent with the existing settlement-window machinery:

• skip_settlement_window inserting a row already closed as rejected mirrors what open_dispatched + close_rejected would produce, and the skip path never calls open_dispatched for the winner (the continue bails first), so the ON CONFLICT DO NOTHING guard can only no-op on a genuine re-execution rather than clobbering a real window.
• The in_flight_orders release path already keys off outcome = 'rejected', so recording the skip there is enough to return the orders to the next cut. close_landed_windows only touches NULL/timeout rows, so a stale landing can't resurrect the window — which is right, since no transaction ever went out.
• Reusing rejected (rather than a distinct skipped outcome) is a reasonable choice; the DB can't tell a driver-rejection from a pre-dispatch skip, but the two are distinguished in the logs.
• record_skipped failing is only a warn!, degrading gracefully to the old behavior (orders held until deadline), matching how open_dispatched failures are treated.
• The new DB test correctly exercises the before/after (1 in-flight → 0 after skip).

Matching on auction_id/solution_uid without solver in the release query is safe because solution_uid is autopilot-generated and unique within an auction, and auction ids are fresh per cycle so no cross-cycle conflict arises.

One minor, non-blocking note: the ?uids log builds a Vec<String> eagerly, but it's inside the !held_out.is_empty() guard so it only allocates when there's actually something held out — negligible.
· solana-autopilot/be-335-release-skipped-winners