refactor: unify submitTx and submitIntent

[micaelae]

Explanation

Before

Currently, submitTx and submitIntent are separate entry points that have overlapping logic. This obscures how the flows differ and some behaviors are inconsistent, although needed by both.

• submitTx inlines long branching for non-EVM, batch/STX/7702, and default EVM paths, with history, rekeying, polling, and analytics mixed into each branch
• submitIntent is a second large path: intent-specific steps (approval, signing, API submit, synthetic tx) with its own history and polling/intent-manager logic

flowchart TB
  subgraph before["Before: two large entry points"]
    ST[submitTx]
    SI[submitIntent]
    ST --> B1{Branch on quote/flags}
    B1 --> N[Non-EVM path]
    B1 --> BA[Batch/STX/7702 path]
    B1 --> E[Default EVM path]
    N & BA & E --> X1[History, rekey, polling, metrics<br/>interleaved per branch]
    SI --> B2{Intent-specific branching}
    B2 --> I[Approval + sign + API + synthetic tx]
    I --> X2[History, polling, intent manager<br/>interleaved in method]
  end

Loading

After

This PR reorganizes tx submission around a strategy (reduce the quote-specific if conditions in the controller) and a command stream (strategies yield step results, and the controller uses those to update history, poll, and publish metrics). Each strategy yields results in their own order.

• The executeSubmitFlow method executes the first strategy that matches the quote and submitTx params
• submitIntent's signature has not changed, but it now forwards calls to submitTx. Intent submission logic is implemented in the intent strategy, not a parallel code path

New shared submit flow

• submitTx: orchestrates tracing, metrics, error handling and executes the strategy. Each SubmitStepResult yielded by the strategy is applied as a controller state update or a side effect
• strategy/*-strategy.ts: async generators that define how each quote type should be processed, and yield order determines when the controller applies results
• utils/: lightweight modules implement calls to other contreollers and other shared logic and to keep strategies concise and readable

flowchart LR
  A[1. submitTx] --> B[2. strategy/index.ts<br/>which matchesFlow?]
  B --> C[3. That *-strategy.ts<br/>read yields top to bottom]
  C --> D[4. utils/* + messenger<br/>inside each yield]
  C --> E[5. submitTx loop<br/>each type → side effect]

Loading

Example dev workflows

Add a step that applies to every flow

1. Extend SubmitStepResult in strategy/types.ts with a new type describing the step
2. In bridge-status-controller.ts, inside the for await loop over steps, handle that type (private method or messenger call)
3. In each strategy generator (evm-strategy, batch-strategy, intent-strategy, non-evm-strategy), yield the step when it should run (order matters)

Add a step to a single flow

1. Same steps as above if the controller needs to process a new side effect
2. Only yield the step from the strategy file that needs it (e.g. only intent-strategy.ts)

Add logic that does not need BridgeStatusController state updates or events

These can stay within the relevant strategy as plain async code (no new SubmitStepResult type) when it does not touch bridge history, polling, or metrics publishing

References

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them