fix: log upstream error body in COMBO per-target failure warnings (#10597)

[diegosouzapw]

Closes #10597

Root cause

The per-target combo failure log line (log.warn("COMBO", "Model X failed, trying next", { status })) discarded the upstream error body even though it was already captured in errorText a few lines earlier (open-sse/services/combo.ts). This is the reporter's Problem #1 ("upstream 400 body is not logged") — operators could not distinguish a context-overflow 400 from a tool_use/tool_result pairing 400 from an auth 400 without reproducing the failing request.

Fix

Added a redacted errorBody field (via the already-imported redactConnectionLabel, reusing the existing 500-char truncation on errorText) to:

• the main per-target COMBO failure log (open-sse/services/combo.ts, handleComboChatInner)
• the COMBO-RR mirror log (handleRoundRobinCombo)

Purely additive to log metadata — no control-flow change.

Scope note: the last-resort compat-fallback debug log (open-sse/services/combo/comboCompatFallback.ts) does not currently capture an error body at all (it only has result.status), so enriching it would require reading the response body there for the first time — out of scope for this surgical fix; left as a follow-up if operators need it too.

Regression test (TDD)

tests/unit/combo-10597-error-body-logging.test.ts — fails on unfixed code (log meta was {"status":400} only) and passes after the fix (the upstream error text now appears in the COMBO warn log).

node --import tsx/esm --test tests/unit/combo-10597-error-body-logging.test.ts

RED before → GREEN after.

Gates run

• node --import tsx/esm --test tests/unit/combo-10597-error-body-logging.test.ts — GREEN
• node --import tsx/esm --test tests/unit/combo-failure-log-message.test.ts — GREEN (pre-existing sibling test on the same log line, unaffected)
• node --import tsx/esm --test tests/unit/combo-quota-share-cooldown-wait.test.ts (isolated) — 7/7 GREEN (two of these flaked under full-suite CPU contention on this shared devbox during the batch combo-*.test.ts run — confirmed unrelated to this diff by re-running in isolation)
• node scripts/check/check-complexity.mjs — OK (2573 violations, baseline 2774)
• node scripts/check/check-cognitive-complexity.mjs — OK (1157 violations, baseline 1223)
• node scripts/check/check-file-size.mjs — no new violations
• node scripts/check/check-changelog-integrity.mjs — OK
• npx eslint --suppressions-location config/quality/eslint-suppressions.json open-sse/services/combo.ts tests/unit/combo-10597-error-body-logging.test.ts — clean
• npm run typecheck:core — exit 0, clean

Notes for the reporter

The revised hypothesis (compression pipeline breaking tool_use/tool_result pairing → Anthropic 400) remains unconfirmed and out of scope here — MALFORMED_REQUEST_PATTERNS in open-sse/services/accountFallback.ts has no entry for "tool_use ids were found without tool_result" yet. Once this ships, please share the newly-logged errorBody from the next production failure so we can confirm/refute that theory before scoping further work.