Settle fast-path orders from the autopilot

[AryanGodara]

Description

When a fast-path order arrives, the autopilot recovers its quote's winning solution and settles it out of competition via the driver's /settle.
Solves BE-62.

Stacked on #4737.

Changes

• on every new order, look up its quote's auction_id, then recover the winning solution + fill from proposed_solutions / proposed_trade_executions
• send the order, its fill (limit) prices, and native prices to the driver that produced the quote, matched by solver address
• add the fastPath payload to the autopilot's /settle DTO

How to test

No automated tests yet: the competition data this reads isn't persisted until BE-56, so the listener is no-op on real orders for now. I verified locally by seeding a competition in local DB (with all migrations) and asserting fast_path_order returns it. The end-to-end test should land once BE-56 and orderbook fast-path support are in.
For those reasons keeping this PR in draft for now

[linear-code]

BE-62

[claude]

Claude finished @AryanGodara's task in 4m 29s —— View job

---

PR Review: Settle fast-path orders from the autopilot

Reviewed against origin/actually-store-quote-competition-data. The earlier review points look addressed — the settle now runs in a spawned task (fast_path.rs:127), initiation is logged with solver/uid/auction_id (fast_path.rs:68), the native-price lookup uses Duration::ZERO, the DB read is a single joined query (single_fast_path_order), and the fill amount is now passed through to the driver (executed/limit_prices). Nice, focused stack.

One substantive finding, posted inline:

• native_prices isn't actually cache-only on a miss (fast_path.rs:79) — estimate_native_price(_, Duration::ZERO) short-circuits only on a cache hit; a miss falls through to a live, un-time-bounded fetch (fetch_prices guards timeout.is_zero(), the singular method does not). Can blow the fast-path window and the doc comment overstates the behavior.

Nothing else blocking from my side. The executed == limit_prices.sell/buy fill relies on the recorded amount exactly matching the signed order for non-partial fills (Static-fee market orders) — worth keeping an eye on once real competition data flows, but consistent with compare_orders already gating the match.

[MartinquaXD]

I don't think this is true. When we send /quote requests we don't send any fee data with the order.
This might actually become quite painful. When the orderbook updates the competition data the executed_sell and executed_buy would already have to account for those fees. 🤕
We definitely need a test asserting that the price at which the order ultimately gets filled makes sense given the original quote, gas usage, and fees (protocol and partner).

[MartinquaXD]

I think this assertion doesn't give us anything. The order could be unsettled immediately after placing it just because the autopilot is a bit slow to kick things off.

[MartinquaXD]

Not sure what this is supposed to prove. The other test has the additional condition that the auction_id must not be the one associated with the quote but here we don't have that. So if we only settle after valid_from due to a bug but still in the original quote auction we wouldn't realize that.