feat: add support for batch sell in quote status manager

[GeorgeGkas]

Explanation

What is the current state of things and why does it need to change?

The QuoteStatusManager reports each quote's on-chain status (SUBMITTED → FinalizedSuccess/FinalizedFailed) to the backend keyed by a single source transaction hash and txMetaId. This worked for the existing single-transaction submission paths, but batch sell flows (EIP-7702 delegated accounts and nested/atomic batch transactions, handled by submitBatchSellHandler in strategy/batch-sell-strategy.ts) can submit multiple quotes under a single batch transaction. Previously there was no way to correlate all of the quotes in a batch to the one transaction hash that actually executes them, so their status reporting and finalization couldn't be tracked correctly as a group.

What is the solution your changes offer and how does it work?

reportSubmitted/reportFinalised on QuoteStatusManager (quote-status-manager/quotes-status-manager.ts) now correlate entries by shared txMetaId rather than assuming a 1:1 quote-to-transaction relationship:

• When a batch sell is submitted, submitBatchSellHandler determines whether the batch produced a single transaction (atomic 7702/nested batch) or multiple independent transactions (e.g. STX/sendBundle), since that determines how the quotes should be tracked (isSingleBatchTx check against unique txMeta.id values).
• For a single-tx batch, every quote sharing that batch is reported as SUBMITTED under the same source transaction hash and txMetaId, and a parent history item plus per-quote nested history items are recorded.
• QuoteStatusEntryStore.getAllByTxMetaId allows reportFinalised to look up all entries sharing a txMetaId and transition/finalize them together once that shared transaction confirms or fails, instead of only handling a single entry.
• For multi-tx batches, each quote keeps its own transaction hash/history item, preserving existing single-quote behavior.

Are there any changes whose purpose might not be obvious to those unfamiliar with the domain?

• The distinction between "atomic 7702/nested batch" (one tx) vs. "STX/sendBundle batch" (many txs) is why submitBatchSellHandler counts unique txMeta.ids rather than trusting is7702Tx alone, a delegated (7702) account can still produce multiple transactions via STX, so is7702Tx being true doesn't guarantee a single shared hash.
• reportSubmitted intentionally no-ops (drops) a submission if the quote has already moved past Submitted for that quote id, this guards against late/duplicate SUBMITTED calls racing with finalization in the batch scenario, since the backend would reject a SUBMITTED call for an entry already in a terminal state.

References

https://consensyssoftware.atlassian.net/browse/SWAPS-4705

---

Note

Medium Risk
Changes backend quote-status lifecycle for batch sells and multi-entry finalization by txMetaId; behavior is heavily tested but incorrect grouping could mis-report quote states.

Overview
Extends quote-status reporting so batch sell flows (atomic EIP-7702 / nested batch with one on-chain transaction) can send SUBMITTED and finalization for every quote under the same source tx hash and txMetaId.

#reportSubmittedOnce now resolves quotes from a batch parent’s quoteIds (child history keys → real quote ids) and calls reportSubmitted for each, with the existing reportedSubmittedTxHash guard still applying once per parent. Startup backfill treats parents with quoteIds as eligible even when the parent has no single quoteId.

QuoteStatusEntryStore.getAllByTxMetaId and QuoteStatusManager.reportFinalised finalize all store entries that share a txMetaId, skipping entries already in a terminal state so duplicate finalization stays safe.

submitBatchSellHandler only builds the parent + nested history shape when the batch produced one distinct txMeta.id (isSingleBatchTx); multi-tx batches (e.g. STX/sendBundle) keep per-quote tracking. BridgeHistoryItem docs clarify quoteIds vs quoteId.

Tests cover batch submit/confirm/fail, startup seeding, rekey edge cases, and store/manager batch finalization.

^{Reviewed by Cursor Bugbot for commit b4cd9f4. Bugbot is set up for automated code reviews on this repo. Configure here.}

[infiniteflower]

Can we get a comment on the types that explain more about quoteId? I think quoteIds is sufficiently explained but quoteId is a little sparse.

[infiniteflower]

I.e. here packages/bridge-status-controller/src/types.ts