feat(solana-solvers): PR 4 solve loop + order handling + engine wiring

[squadgazzz]

Description

PR 4 of the Jupiter solver plan (after #4632, #4635, #4637, #4652): make /solve return real solutions. Until now the handler took an auction and answered with an empty list. This wires the existing pieces (the /solve endpoint from PR1, the Jupiter adapter from PR2, solution assembly from PR3) into a working solve loop.

For each order the solver asks Jupiter for a swap and turns it into a single-order solution, quoting all orders at once. Buys (when disabled) and orders Jupiter cannot route drop out with no candidate, and the rest of the auction still returns solutions. A full Jupiter outage yields an empty solution set, not a crash.

Stacked on PR3 (#4652).

Changes

• domain::solver: the solve loop, plus a Quote seam over Dex so the loop is testable without the network. It quotes every order concurrently and maps each routable swap into a Solution, leaving out buys and orders Jupiter cannot route.
• domain::auction: the inbound /solve auction DTO (id, taker, orders). Proposed shape, since the driver spec pins the response and not the request.
• /solve now runs the loop and returns the solutions. run.rs builds the Jupiter Dex from config and hands it to the API.
• OrderUid gains FromStr (hex) so it parses inbound, and Side gains Deserialize.

How to test

New unit tests.

[linear-code]

BE-145

[tilacog]

@squadgazzz
I'm finding it odd that we don't ever specify the sell_token account.
I tried searching in Jupiter's docs but I couldn't find how the routing API defines that.

Should we assume that account is implicitly derived as the solver's ATA?

[squadgazzz]

Should we assume that account is implicitly derived as the solver's ATA?

@tilacog, yes. Jupiter's swap API has no source-account parameter, the route always spends from userPublicKey's ATA for the input mint, and only the destination can be overridden (we use that to deliver into the buy-mint buffer).

Since userPublicKey is the settlement signer, the sell account is ATA(solver_keypair, sell_mint). The driver has to match that: BeginSettle's pull destination is solver-specified, right? So it pulls to the same ATA and creates it idempotently, since we pass skipUserAccountsRpcCalls and Jupiter emits no setup instructions.

I'll add a doc comment on dex::Order to explain this.