solana-orderbook: accept sponsored orders on Token-2022 tokens

[squadgazzz]

Description

A sponsored order is placed through POST /api/v1/orders as a creation transaction that CoW's funder account pays for. So the orderbook only accepts the instructions a fixed template allows before CreateOrder: wrap SOL, delegate the sell account to the settlement program, create the buy token account. The template hardcodes the SPL Token program. For Token-2022 tokens the frontend builds the delegation and the buy account creation under Token-2022, so those orders fail with InvalidTransaction.

Just allowing both programs would let two kinds of broken orders through. A step naming a program that doesn't own its mint passes placement, but its creation transaction fails at settlement, so the user sees an accepted order that never fills. And some Token-2022 mints can't settle at all. The settlement program pays out with a plain Transfer, which Token-2022 refuses for mints with a transfer fee, transfer hook or pausable extension (even while unpaused) and for non-transferable mints. #5003 keeps those orders out of auctions, so placement should refuse them too.

This PR allows Token-2022 in those two steps and rejects both kinds of broken orders. After the template check, placement reads the sell and buy mints in one getMultipleAccounts call. The wallet check of a native SOL buy from #4990 joins that call. A native SOL buy has no buy mint to read, since its buy token is the System Program ID. POST /api/v1/quote runs the same mint check where sponsoring is configured, so the frontend finds out before the user signs. The mint rule is the solana-token crate from #5003. This PR is stacked on #5003 and merges after #5002 and #5003 are deployed.

Changes

• The delegation (approve, approve-checked) and buy account creation steps accept Token-2022. Sync-native and the wSOL account creation still need SPL Token, which owns the wSOL mint.
• Placement rejects a step whose token program doesn't own its mint with InvalidTransaction
• Placement and quotes answer UnsupportedToken (the EVM error type) for a token that isn't a mint of either token program, and for mints with a transfer fee, transfer hook, pausable or non-transferable extension, or a frozen default account state. A native SOL buy only has its sell mint checked.
• Placement reads the mints and a native SOL buy's wallet in one lookup
• The orderbook only has an RPC client when sponsoring is configured, which placement needs anyway, so quotes check mints only on those deployments. A failed read quotes unchecked, since placement and the autopilot check again.

How to test

New unit and API tests, one against the DB. Before merge, a barn run: place a sponsored order on a plain Token-2022 token from the frontend, and check that a PYUSD quote answers UnsupportedToken.

Related issues

BE-339

[linear-code]

BE-339

[github-actions]

Reminder: Please consider backward compatibility when modifying the API specification.
If breaking changes are unavoidable, ensure:

• You explicitly pointed out breaking changes.
• You communicate the changes to affected teams (at least Frontend team and SAFE team).
• You provide proper versioning and migration mechanisms.

---

Caused by:

• crates/solana-orderbook/openapi.yml