fix(model): route to custom node when prefix collides with built-in provider alias

[dnd21052002]

Problem

When a user creates a custom openai-compatible node whose prefix matches a built-in provider alias, requests to that prefix fail with No active credentials for provider: <name>.

Reproduction:

1. Create a custom openai-compatible node named tokenrouter with prefix tr (the built-in tokenrouter provider also uses alias tr)
2. Add an API key connection to that node
3. Send a request with model tr/qwen/qwen3.8-max-free
4. Result: No active credentials for provider: tokenrouter

Root cause: In src/sse/services/model.js, the RESERVED_PROVIDER_PREFIXES guard skips the custom-node lookup when the prefix matches any built-in provider id/alias. The request is routed to the built-in provider, but the user's credentials are stored under the custom node's ID → credential lookup returns 0 results.

This is a regression of #1756 (same symptom, same root cause pattern).

Fix

Check custom provider nodes first. If the user explicitly created a node with a given prefix, route to it even when the prefix collides with a built-in provider id/alias. Only fall through to built-in provider resolution when no custom node matches.

This is the correct precedence: explicit user configuration (a created node + stored credentials) should always win over implicit built-in defaults.

Changes

• src/sse/services/model.js — remove RESERVED_PROVIDER_PREFIXES guard; always check custom nodes before falling back to built-in resolution
• tests/unit/model-routing.test.js — update collision test to assert custom-node-first behavior; add regression test for the tr/tokenrouter case

Testing

• Existing test still routes non-reserved compatible node prefixes still passes (unchanged behavior for non-colliding prefixes)
• Updated test verifies custom node wins over built-in cf (cloudflare-ai) alias
• New test reproduces the exact tr/tokenrouter scenario from the bug report