[High] Build a single MSW-based mock API and fixture system shared by dev, Vitest, Playwright and Storybook

[james2177]

Category: Testing, Design System & Community Tooling

Description: Mocks are currently ad hoc (Playwright route stubs in e2e/swap-happy-path.spec.ts, in-memory governance data, per-test vi.mocks). Create a unified Mock Service Worker handler set, typed fixtures and scenario switches used everywhere.

Problem Statement & Context: Contributors cannot run the frontend without the backend, and each test suite re-invents responses, which drift from real API shapes. A central mock layer also unlocks features that depend on not-yet-built endpoints (feature-flagged adapters in other issues).

Scope & Acceptance Criteria:

• src/mocks/{handlers,fixtures,scenarios} implementing every endpoint used by the app (intents, feed, quote, solvers, open intents, governance, config/assets) with realistic data generators (seeded), latency/error injection and stateful behaviours (creating an intent updates lists; WS mock server pushes transitions).
• Used by: npm run dev:mock (browser service worker + a mock WebSocket server), Vitest (setupServer), Storybook (msw-storybook-addon-equivalent), and Playwright (route fulfilment through the same handlers/Node server).
• Scenario switches (?mock=empty|error|slow|large) for reproducing UI states; documented catalogue of scenarios.
• Fixtures validated by the runtime schemas in tests (contract safety); no production bundle impact (dev-only import guarded, verified by bundle checks).
• Out of scope: replacing the real backend in staging.

Implementation Guidelines (Suggested Execution):

1. Key Files/Modules: new src/mocks/*, vitest.setup.ts, e2e/*, .storybook/preview.tsx, src/lib/schemas.ts, docs/testing.md.
2. Design/Architecture: Handlers written once against a typed route table; a tiny in-memory "database" per scenario.
3. Edge Cases/Constraints: MSW service worker + CSP (worker-src), Node vs browser handler compatibility, WebSocket mocking (MSW WS support or a dedicated dev server), HMR restarts.
4. Testing: Existing tests migrated where they benefit; tests for stateful scenarios; ≥ 85% coverage of mock logic.

Definition of "Done": Baseline DoD, plus README quick-start for "run the frontend without a backend".

Resources: MSW docs, e2e/swap-happy-path.spec.ts.

Complexity: High (200 points)

Baseline Definition of Done (applies to every Wave issue)

Each issue's own "Definition of Done" is in addition to this baseline:

• Code, tests and documentation are included in one PR that references the issue.
• npm run lint, npm run typecheck, npm test, npm run check:i18n and npm run check:editorconfig pass locally and in CI. (If a command is broken by pre-existing repo debris, see the Repository Health & Build Integrity issues — do not silence the check; note the blocker in the PR.)
• No new any, no // @ts-ignore / eslint-disable without a justification comment, and no new console.* (use secureLogger from src/lib/secureLogging.ts).
• All new user-facing strings go through the i18n catalog (src/lib/i18n/messages/en.ts and es.ts).
• New interactive UI is keyboard-operable, has visible focus, correct ARIA semantics, and works in both the dark and light palettes defined in src/app/globals.css.
• UI changes include before/after screenshots (desktop and ~400px mobile). Behaviour changes include a short screen recording or test output.
• Relevant docs under docs/ (and README.md if routes/scripts/env vars change) are updated.
• The PR is reviewed and approved by a maintainer listed in .github/CODEOWNERS.