[rafacpti23]

Summary

Fixes #14135

For custom provider nodes (e.g. openai-compatible-chat-<uuid>) configured with a prefix alias (e.g. of), the combo builder previously used the raw provider ID when constructing qualifiedModel for provider node options, causing:

1. Combo steps to serialize with the raw node UUID instead of the prefix alias.
2. Capability and catalog resolution (such as in /v1/models) to fail looking up the canonical prefix.

This change ensures that custom provider nodes (providerVisual.source === "provider-node") with a configured alias use their alias prefix as routingPrefix in getComboBuilderOptions().

Testing

• Added unit test in tests/unit/combo-builder-custom-provider-alias-14135.test.ts verifying prefix alias qualifiedModel assignment, global model list step building, and manual combo step resolution.
• Validated with node --import tsx/esm --test tests/unit/combo-builder-custom-provider-alias-14135.test.ts (100% pass).
• Verified related combo tests pass without regression.

[diegosouzapw]

Solid catch and a clean fix — gating on providerVisual.source === "provider-node" is exactly right, so system providers and the existing opencode special-case keep their current behavior while custom nodes get their configured alias instead of the raw DB UUID. I reverted just this hunk locally to confirm the new test actually fails without it (raw openai-compatible-chat-<uuid>/... instead of of/...), then reapplied it and it passes — good regression coverage. Merging.

[diegosouzapw]

Thanks @rafacpti23 — merging via the release merge-train. Validated in local merge-train (mt-train10c) on the devbox @ train tip 4d841aa1c740bbaa03868dc0a403c62099a99a42 with the 72 sibling PRs of this batch: typecheck:core, file-size, complexity, cognitive-complexity, changelog-integrity green; changed-area node:test 831/831 (0 failing) and vitest 480/482 — the two reds are autoCombo/provider-family-combos.test.ts timing out at 20s, which reproduces on the PURE release tip under the full vitest suite (and is already tracked by the Release-Green issue #13866), so it is inherited, not this batch's. Merged --admin per merge-gates §3/§4/§7.