fix(logging): prefer the pipeline over the raw bodies in call-log storage and detail enrichment

[maxmad64bis]

⚠️ base-red inherited: #12732

Summary

A call log stores the same exchange twice: the raw client bodies, and pipeline — both sides translated, plus what the provider actually replied. Two places picked the wrong copy.

Past the size budget, the ladder dropped pipeline first, keeping a prompt it already had a copy of and losing the upstream answer. resolvePreviousResponseState (src/lib/db/responsesContinuationStore.ts:91) rebuilds previous_response_id history out of pipeline, so a long agentic conversation crossing the budget also lost server-side continuation and had to resend everything. The bodies go first now, and only when there's a pipeline to keep in exchange.

In the request-detail panel, maybeEnrichCompletedDetail reads the pipeline then falls back to responseBody — but it decided which sides were empty before reading anything, so the fallback overwrote what the pipeline had just supplied. responseBody is one value used for both sides, so the panel could show a provider payload as the client response. It's re-checked per side now. It ships here because the first fix makes it worse: the size-limit placeholder is a non-empty string, so it would have replaced a good payload with "[omitted: ...]".

The ladder was five copy-pasted stringify/measure/return blocks over two functions; it's an ordered list and one loop now.

Related Issues

Related to #12420 (overflow on large tool results), which stays open: the reporter says the request itself fails, and an oversized artifact never fails a request (writeCallArtifact catches and returns null). This changes which payload survives the cap, not the cap.

Same shape as #12095, which kept the error alive through this ladder.

Validation

• Change type: DB
• Focused tests and category gates from the golden path
• npm run lint
• Reconciled with the current active release base; focused checks rerun afterward
• Production-code changes include a new or updated automated test in this PR

71/71 — 10 new, 61 existing across call-log-{size-limit-error,cap,stream-debug,artifact-worker,save-drain,oom-unbounded-5618}, log-export-runner and responses-continuation-store, each suite run on its own. typecheck:core and lint exit 0, on the tip of release/v3.8.51.

Tests Added Or Updated

call-log-artifact-bodies-first.test.ts — 5 cases: body-heavy overflow keeps pipeline.providerResponse; pipeline-heavy keeps today's shape; both-heavy falls through to today's minimal; no pipeline is stored exactly as before; a stored body is detectable as a placeholder, not merely truthy.

completed-detail-pipeline-precedence.test.ts — 3 cases, written first and red on the base (1 and 3 failing, 2 passing: an inverted precedence, not a broken fallback): a body doesn't overwrite a side the pipeline filled; it still fills a side no pipeline covered; a half-filled pipeline keeps its side.

Coverage Notes

Old and new serialization replayed over every fixture in the existing suites: same bytes except on the one exercising the new rung, so no existing expectation needed touching.

Reviewer Notes

The tradeoff: on a large 200 (big response body next to a big pipeline, e.g. agentic tool loops) the stored shape flips from bodies-kept/pipeline-dropped to bodies-dropped/pipeline-kept — only the pre-translation client payload is lost. Cost is one extra JSON.stringify on the oversize path, and only for artifacts with a pipeline; without one the new rung isn't in the list at all.

Left alone on purpose: the loop still stops as soon as either side is filled. No test proves that wrong and it predates this change.