Implement bitget /swap adapter for solana solver

[AryanGodara]

Description

Makes the Bitget engine quote real sell orders. Each order is one signed call to Bitget's /swap endpoint. This version doesn't need Bitget to co-sign, and pays Bitget's 1 bp fee on every order instead. Sell orders only; buy orders return order-not-supported.

Changes

• One POST /swap per order, with market bgwaggregator (which skips /quote) and amounts in atoms.
• Bitget pays the solver's buy-token ATA, so the adapter appends a transfer of minAmount into the settlement's buy buffer. Positive slippage stays with the solver.
• ComputeBudget instructions are dropped, and a route that needs a signer other than the solver is rejected.
• max-accounts (sent as solMaxAccounts, default 48) leaves room for the settlement's own 7–8 accounts within the 64-account limit.
• Error mapping follows the EVM engine: 429 is rate limited, and Bitget's no-route codes are not found.
• Jupiter's instruction DTO moves to dex/dto.rs, shared by both adapters.
• The endpoint works with or without a trailing slash.

How to test

• Added unit tests
• Tested on staging, corresponding PR: https://github.com/cowprotocol/infrastructure/pull/7265

Closes BE-253

[linear-code]

BE-253

[claude]

Claude finished @AryanGodara's task in 2m 1s —— View job

---

PR Review: Bitget /swap adapter

• Read PR diff vs origin/aryan/be-252-bitget-scaffold
• Review bitget adapter (mod.rs, dto.rs)
• Review config + shared DTO refactor
• Post inline comments
• Post summary

Overall this is clean, well-documented work. The ApiInstruction extraction into a shared dex/dto.rs is a nice dedup, the signer/ComputeBudget filtering and ATA-transfer logic are clear, and the error mapping mirrors the EVM/Jupiter engine. Test coverage is good (unit + ignored live tests). Only one minor robustness point worth considering:

• SwapResponse deserialization is less lenient than Jupiter's — inline comment. address_lookup_table_account (and instruction_lists) lack #[serde(default)], so a Bitget response that omits/nulls the lookup-table field (e.g. a direct route with no LUTs) fails to parse and the order gets dropped as BadResponse. Adding a default keeps it consistent with the Jupiter DTO and more forgiving.

A couple of things I checked and found fine (no action needed): the signed body string is reused verbatim for the HTTP body so the HMAC can't drift; the trailing-slash normalization + join("swap") is correct; the extra-signer rejection runs before the taker-authorized transfer is appended; and mapping transient Bitget error codes to NotFound for next-auction retry is a reasonable design choice.
· aryan/be-253-bitget-adapter

[claude]

Unlike the Jupiter DTO (which marks address_lookup_table_addresses, setup_instructions, and cleanup_instruction with #[serde(default)]), neither instruction_lists nor address_lookup_table_account has a default here. If Bitget ever omits (or sends null for) addressLookupTableAccount — e.g. a direct route that uses no lookup tables — deserialization fails outright and the order is silently dropped as BadResponse instead of being quoted. Consider adding #[serde(default)] to be defensive and consistent with the Jupiter adapter:

Suggested change

	instruction_lists: Vec<ApiInstruction>,
	#[serde_as(as = "Vec<DisplayFromStr>")]
	address_lookup_table_account: Vec<Pubkey>,
	instruction_lists: Vec<ApiInstruction>,
	#[serde(default)]
	#[serde_as(as = "Vec<DisplayFromStr>")]
	address_lookup_table_account: Vec<Pubkey>,

[AryanGodara]

"Every /swap response i saw had addressLookupTableAccount, and a missing field already logs as quote failed.