[Slice 5] Security regression test suite for session routes

[field123]

Parent PRD

#317

What to build

A CI-enforced security regression test suite that asserts no admin-tier credential or token ever appears in any session-route response body. This catches future regressions where someone accidentally serializes the wrong field, returns a server-side token to the client, or otherwise breaks the server/client boundary established in Slice 1.

This slice is purely additive: no production-code change. It adds tests that exercise all five session routes (or six after Slice 4) with realistic mocked EP responses, then asserts that the response payload contains none of:

• The string "client_credentials" (would indicate the grant type leaked into a response).
• The literal value of EP_CLIENT_SECRET (would indicate the secret leaked).
• A Stripe client_secret value (the cart payment intent client secret should never travel back to the host JSON body — it's relayed via the session payload's typed clientToken field already used by EPStripePayment, but stricter assertions verify this is the only path).
• Any Authorization header value or Bearer prefix in the body.

The intent is to make the boundary visible-by-test, so a future code review or AI code change that breaks it gets a red CI build immediately.

Cuts through every layer:

• Package — tests. New test file alongside the existing handler tests. Covers every route. Uses realistic mock EP SDK responses (success, error, requires_action for the 3DS route once Slice 4 lands). Asserts on response body strings and headers.
• Package — types (defensive). The ClientCheckoutSession type that handlers return continues to exclude server-only fields. Add (or strengthen) a comment on the type explaining the security boundary so future contributors understand why fields are scoped.
• Documentation. A short note in COMPONENTS.md (or successor) documenting the test as the canonical security boundary check.

See parent PRD §Testing Decisions → "Security regression tests" for full detail.

Acceptance criteria

• One test file (or a clearly-grouped test block) covers all currently-mounted session routes.
• Each route is exercised with at least one realistic mocked EP response: a success path, an error path, and (for /pay and /resume-payment after Slice 4) the requires_action path.
• For each fixture, the test asserts the response body (parsed JSON, then re-serialized for substring matching) contains none of: "client_credentials", the literal EP_CLIENT_SECRET test fixture value, the Bearer prefix, or "Authorization" header strings.
• For /pay and /resume-payment: the test asserts the response body does not contain the EP API access token used in the mocked SDK call.
• For payment-related routes: the test asserts that any Stripe client_secret in the response is only present in the typed payment.clientToken field, not in any other field name, error message, or stack trace.
• Tests fail loudly if any future code change introduces a leaked token (verified by introducing a deliberate leak in a scratch branch and observing the test failure).
• Test suite runs as part of the package's standard yarn test and (transitively) the project's CI.
• A short COMPONENTS.md (or successor) note documents the test as the canonical security boundary check.

Blocked by

• Blocked by [Slice 1] Anonymous guest checkout — full happy path #321

User stories addressed

Reference by number from the parent PRD:

• User story 18
• User story 28
• User story 29
• User story 30