Build an integration test harness with a mock API server

You are a senior engineer who writes deterministic integration tests for API clients.

Build an integration test harness with a mock server for an API client. Context:
- Client under test: [DESCRIBE — e.g. 'an OpenAI chat client with retries and streaming']
- API shape: [OpenAI / Anthropic / custom REST — describe the endpoints]
- Language and test runner: [TypeScript + Vitest / Python + pytest / other]
- Mock server: [MSW / nock / httpretty / a real local server]
- Scenarios to cover: [LIST — e.g. 'happy path, 429-then-success, 500-give-up, abort mid-stream, malformed JSON']

Build a harness with:
1. A mock server that starts and stops per test (or per suite) on an ephemeral port, so tests are isolated and parallel-safe.
2. Fixtures for each scenario — canned request/response pairs, including streaming responses served as SSE and malformed or error payloads.
3. Assertions that the client behaves correctly per scenario: success returns typed data; 429 triggers a retry then succeeds; 500 after max retries raises the right typed error; abort cancels an in-flight stream; a malformed response raises a parse or validation error.
4. Request verification: assert the client sent the right method, path, headers (auth present, no leaked secrets), and body for each scenario.
5. Determinism guarantees: no real network, no flaky sleeps (use fake timers or event-based waits), fixed ports or dynamic with capture.
6. A clear way to add a new scenario from a real captured response (record-once, replay-after), documented in a comment.

Requirements:
- Tests must pass offline in CI with no API key and no internet.
- Each test isolates state; no cross-test leakage.
- Secrets are never present in fixtures or logs; redact on capture.

Output, in this exact order:
1. A design overview (mock server, fixtures, isolation, determinism).
2. The harness setup file (server start/stop, helpers).
3. At least four representative scenario tests, one per category: success, transient-error-then-retry, give-up-after-max-retries, abort-mid-stream.
4. The 'add a new scenario' guide with a worked example.
5. A checklist: offline, parallel-safe, no sleeps, no secrets in fixtures.

Success signal: the output is good only if the full suite passes offline with no API key, each scenario asserts both correct client behavior and correct outbound request shape, and adding a new recorded scenario is documented and mechanical.