[E2E] Mock API calls for deterministic tests

[CassioMG]

Goal

Make E2E tests deterministic by mocking all API calls/dependencies (RPC/Horizon/Blockaid/stellar.expert requests/responses, etc.) so that:

• Tests don’t depend on live backends or network flakiness.
• Assertions are stable and repeatable (e.g. balances, token lists, swap quotes).
• CI runs are faster and more reliable.

At the same time, keep optional “true” integration test flows that hit real backends, to be run:

• Strategically (e.g. once per night on main), and/or
• Manually (e.g. right before a release or after backend changes).

Current state

• E2E flows (CreateWallet, ImportWallet, SendClassicToken, SwapClassicToken) run in CI with IS_E2E_TEST=true and real backend URLs (FREIGHTER_BACKEND_V1_*, FREIGHTER_BACKEND_V2_*, Wallet Kit, etc.).
• Some app behavior is already gated for E2E (e.g. ATT/analytics skipped when isE2ETest).
• There is no central API-mocking layer for E2E; tests depend on live services.

Proposed direction

1. Introduce API mocking for E2E

   • When running in E2E mode, intercept or replace all outbound API calls with deterministic responses (e.g. local mock, MSW, custom fetch/axios interceptor, or backend stub server).
   • Use fixed fixtures for balances, token lists, swap quotes, RPC, etc., so UI assertions don’t depend on real backend state.

2. Keep optional integration flows

   • Define a small set of flows (or a “full integration” mode) that do use real backends.
   • Run them only when intended:
     • Scheduled (e.g. nightly workflow on main), and/or
     • Manual trigger (e.g. workflow_dispatch with an “integration” input or a separate workflow).

3. Investigation and strategy

   • We can use the Freighter extension implementation as inspiration: Make e2e tests more reliable freighter#2562
   • From that, define a concrete strategy for freighter-mobile: where to plug in mocks (have a similar stubAllExternalApis if applicable, network layer, API client, etc.), how to toggle “mocked E2E” vs “true integration,” and how to organize fixtures.

Note: share design doc with team before implementing it