fix(routing): honor edited custom-node API type

[pacocartones]

Summary

• Honor an edited custom OpenAI-compatible node's saved Chat/Responses API type at dispatch time.
• Keep the credential-blind effective format available for existing callers, but forward only an explicit custom-model DB override as modelInfo.targetFormat, so chat core's credential-aware resolution picks the live connection setting instead of the format baked into the node id at creation.

Related Issues

• Closes fix(providers): Changing Custom Node API Type (Chat vs Responses) has no effect at runtime in v3.8.50 (regression from v3.8.49) #11884
• Related to fix(providers): vertex-partner Claude models fail "Expected input to contain field: messages" #8994

Validation

• Change type: routing
• Focused tests and category gates from the golden path: tests/integration/chat-pipeline.test.ts (#11884 chat pipeline sends a custom node's edited Chat API type upstream) 1/1, tests/unit/chat-helpers.test.ts 28/28, npm run typecheck:core exit 0, focused ESLint exit 0, git diff --check clean, check:changelog-integrity OK
• npm run lint — exit 0 with --pass-on-unpruned-suppressions; the literal command exits 2 only because the merged base leaves unused global suppressions (eslint 10), no rule violation reported
• Reconciled with the current active release base release/v3.8.51@158647618; focused checks rerun afterward
• Production-code changes include new automated tests in this PR
• SonarQube is temporarily opt-in while the private project has no quota; it is not a PR gate.

Regression proof at the sink: with the src/sse/handlers/chat.ts forwarding hunks reverted, the new integration test fails (the saved Chat API type must produce a Chat Completions body, the upstream body is Responses-shaped); with the fix restored it passes.

Pre-existing, unrelated: three other cases in tests/integration/chat-pipeline.test.ts fail identically on the untouched base with upstream 410 "Model claude/claude-3-5-sonnet-20241022 was shut down" / 502.

Tests Added Or Updated

• tests/integration/chat-pipeline.test.ts — creates a custom node whose id still encodes the Responses type, edits it to Chat through the real PUT /api/provider-nodes/[id] handler, drives handleChat with a strict globalThis.fetch double and asserts the captured upstream call is POST {baseUrl}/chat/completions with a messages body and no input.
• tests/unit/chat-helpers.test.ts — #11884 configured Chat API type wins after custom-node model resolution pins the resolver-level customModelTargetFormat contract.

Coverage Notes

• src/sse/handlers/chat.ts and src/sse/handlers/chatHelpers.ts are exercised by both tests above; the integration test covers the full request path through the fetch sink.
• No file's coverage moved down.

Reviewer Notes

• The node id keeps encoding the creation-time API type on purpose (ids are immutable); the fix changes only which value wins at dispatch.
• Behaviour for nodes that were never edited is unchanged: the explicit override is only forwarded when a custom-model DB override exists.