…hrough

When the upstream rejects a request with `previous_response_not_found`
(response was created by a different account, the in-memory affinity map
was lost on restart / 4h TTL expiry, or rotation forced the request onto
a different account), the proxy now strips the stale `previous_response_id`
+ `turnState`, retries once on the same account, and forgets the stale
entry from `SessionAffinityMap` so subsequent requests aren't routed to
the same wrong account.

Two halves are required because the error reaches the proxy as an
in-stream WS frame, not as a synchronous HTTP error:

1. `ws-transport.ts:36` — add `previous_response_not_found: 400` to
   `ROTATABLE_ERROR_CODES` so the first-frame error is converted to a
   `CodexApiError` reject, letting the proxy-handler catch block run.
2. `proxy-handler.ts` — in the catch, detect via the new
   `isPreviousResponseNotFoundError` classifier, reuse the existing
   `restoreImplicitResumeRequest()` path (so implicit-resume requests
   replay the full input losslessly), then clear the stale ID + turn
   state and retry. A `prevRespNotFoundRetried` flag prevents looping
   if the second attempt also fails.

Implicit-resume scenarios recover losslessly. Explicit-resume requests
(client-supplied `previous_response_id`) lose server-side history but
still complete with the latest input — better than a hard error that
most clients can't gracefully handle.

Verified end-to-end against real chatgpt.com upstream: 3/3 successful
recoveries with `affinity=miss` + `previous_response_not_found` →
`stripping and retrying same account` → 200 OK.