fix(sse): bridge generic compatible-provider type id to concrete node id in credential lookup

[diegosouzapw]

Closes #10085

Root cause

getProviderSearchPool (src/sse/services/auth.ts) built the credential
search pool for a custom OpenAI-compatible / Anthropic-compatible provider
node by bridging the searched provider string to a node id only via the
node's prefix. It never bridged the generic derived type id
(openai-compatible-chat, openai-compatible-responses,
anthropic-compatible) to the node's concrete uuid node id
(openai-compatible-chat-<uuid>), even though
resolveProviderNodeForConnection (src/lib/db/providers/nodes.ts, #4421)
already accepts the bare generic type id at connection-creation time.

Result: a connection persisted under the generic type id (e.g. via
/api/providers posting the bare type) became permanently unreachable from
the chat path, which resolves the concrete uuid node id — surfacing
No active credentials for provider: openai-compatible-chat-<uuid> even
though the API key and model catalog were valid. The provider "Test" button
and /v1/models catalog hit the upstream directly and never touch
provider_connections, which is why those "worked" while chat failed.

Fix

Expand the custom-provider node-expansion loop in getProviderSearchPool to
also add a node's nodeId to the search pool when the searched provider
equals that node's generic derived type id (via nodeTypeFromId, the same
UUID-stripping helper resolveProviderNodeForConnection uses), and
symmetrically add the generic type id when the searched provider is the
concrete node id — mirroring the creation-time resolver so the two paths
agree.

Regression test

tests/unit/10085-compatible-generic-vs-uuid-credential.test.ts (adapted
from the plan-file's RED probe):

• generic-type-stored connection found via uuid-node-id lookup (was the bug)
• uuid-stored connection found via generic-type-id lookup (symmetric direction)
• control: uuid-stored connection found via uuid-node-id lookup (unchanged)
• control: uuid-stored connection found via prefix lookup (unchanged)
• negative: bridge does not leak into an unrelated generic type (chat vs responses)

node --import tsx/esm --test tests/unit/10085-compatible-generic-vs-uuid-credential.test.ts
ℹ tests 5
ℹ pass 5
ℹ fail 0

Gates run

• npm run typecheck:core — clean
• npx eslint --suppressions-location config/quality/eslint-suppressions.json src/sse/services/auth.ts tests/unit/10085-compatible-generic-vs-uuid-credential.test.ts — clean
• node scripts/check/check-test-discovery.mjs — OK, new test file discovered, no new orphans
• node scripts/check/check-complexity.mjs / check-cognitive-complexity.mjs could not complete locally within a reasonable window due to devbox saturation from a large parallel fan-out (many check-complexity.mjs processes contending simultaneously); the change is a small, flat, early-return addition inside an existing loop, and CI (quality-gate job) will validate it.
• Full npm run test:unit was not re-run locally for the same saturation reason; the targeted regression file is green and the change touches no other call sites of getProviderSearchPool.

⚠️ base-red inherited: #9985 — ESLint errors (2) from #10250 (unrelated i18n PT-PT translation, pre-existing on the release tip)