fix(responses-continuation): chain off the effective post-reconstruction input, not the pre-reconstruction client bytes

[hartmark]

What Problem This Solves

previous_response_id continuation (OmniRoute-native virtualization,
src/lib/db/responsesContinuationStore.ts) silently corrupts conversation
history a few turns into any tool-heavy exchange: the reconstructed request
degrades to a handful of bare tool-call items with no leading system/user
message, which the upstream provider then rejects outright.

Why This Change Was Made

resolvePreviousResponseState() reconstructs a continued turn's full history
by reading the prior call-log's clientRawRequest.body.input. But
clientRawRequest is deliberately captured before chat.ts's own
previous_response_id reconstruction runs
(captureDeferredClientRawBody's whole point — it has to preserve the raw
client bytes for audit/guardrail purposes, not what OmniRoute rewrote the
request into).

For a prior turn that was itself a continuation, body.input is just the
client's own trimmed delta (relying on OmniRoute to have already
reconstructed history server-side) — not the full input that actually
dispatched. Chaining a later continuation off that instead of the real
effective input compounds: each hop's stored "input" is only the prior hop's
already-trimmed delta, so a few turns into a tool-heavy conversation the
reconstruction degrades to a handful of bare tool items with nothing before
them.

Live incident (2026-09-03): a real production session's 3rd turn failed
with a Gemini 400 — Please ensure that function call turn comes immediately after a user turn or after a function response turn — because OmniRoute
sent exactly that malformed 3-item request
(function_call_output, function_call, function_call_output, no leading
system/user message) upstream.

Fix

Capture the actual effective input a request dispatches with — after
previous_response_id reconstruction runs, whether or not it applied this
specific turn — as a new sibling field on clientRawRequest
(effectiveInput), threaded through the existing logClientRawRequest /
logClientRawRequestRedacted call chain. No new parameter threading needed
anywhere else in the request pipeline.

resolvePreviousResponseState now chains off effectiveInput, falling back
to body.input only for artifacts logged before this field existed (no
compat migration needed — self-healing: any conversation naturally recovers
correct reconstruction the moment one of its turns is logged post-fix).

User Impact

• Multi-turn continuation for previous_response_id no longer degrades or
  corrupts history a few turns into a tool-heavy conversation.
• No behavior change for a turn that was never itself a continuation (its
  effectiveInput always equals body.input in that case).
• No config surface added.

Evidence

tests/unit/responses-continuation-store.test.ts:

• New case "chains off effectiveInput, not the pre-reconstruction
  clientRawRequest.body" — proves a continued turn correctly reconstructs
  the full 4-item history from effectiveInput instead of the 1-item raw
  delta. Fails on pre-fix code (returns just the delta item); passes
  after.
• New case "falls back to clientRawRequest.body.input when effectiveInput
  is absent (pre-fix artifacts)" — proves legacy artifacts without the new
  field still resolve exactly as before (no regression for existing data).

Full file: 13/13 passing. tsc --pretty false -p tsconfig.typecheck-core.json
clean on all 4 touched production files.