[pacocartones]

A custom OpenAI-compatible connection pointing at a keyless local backend is silently dropped from every auto/* candidate pool. It never appears as a routing candidate, so no strategy, weight or priority setting can select it, while direct <provider>/<model> calls keep working.

Root cause

open-sse/services/autoCombo/virtualFactory.ts:489 filters the pool through hasUsableConnectionCredential, which requires one of three things:

const hasApiKey = typeof conn.apiKey === "string" && conn.apiKey.trim().length > 0;
return hasApiKey || hasUsableOAuthToken(conn) || hasProviderSpecificSessionData(conn);

A keyless local endpoint has none of them: api_key is NULL, there is no OAuth token, and there is no web session data. The connection is removed before the pool is built.

This is one gate later than #5873. That fix made the registry-absent path fall back to defaultModel, and it still works; the connection's models do get enumerated. It is then dropped by the credential filter.

Fix

Treat the four generated compatible-provider ID shapes as credential-optional, reusing the existing isCompatibleProviderConnectionId helper rather than a new inline regex (the lesson of #8326, where an inline pattern matched only 1 of the 4 shapes).

Deliberately narrow. A first-party provider with an empty key really is unconfigured and stays filtered out, and AUTO_COMBO_NOAUTH_ALLOWLIST is untouched, so this does not widen the no-auth registry policy.

Red / green

Before, on a clean checkout at 62ab93d78:

✖ keyless custom openai-compatible connection enters the auto pool (#11180)
  AssertionError: a keyless custom-compatible connection must not be dropped by the credential gate
  actual: undefined, expected: true
✔ a keyless FIRST-PARTY provider connection stays out of the pool (#11180)
ℹ pass 1  ℹ fail 1

After:

✔ keyless custom openai-compatible connection enters the auto pool (#11180)
✔ a keyless FIRST-PARTY provider connection stays out of the pool (#11180)
✔ createVirtualAutoCombo includes custom openai-compatible providers via defaultModel (#5873)
✔ fresh install: the allowlisted no-auth providers are present in the auto-combo pool
✔ fresh install: non-allowlisted no-auth providers are EXCLUDED from the auto-combo pool
✔ fresh install: EVERY synthetic-noauth candidate belongs to an allowlisted provider
ℹ pass 6  ℹ fail 0

The second test is a negative control: it fails if the relaxation is ever widened to first-party providers. noauth-autocombo-allowlist, -exclude-7622, -hidden-7620 and -lockout-7623 were also run and stay green.

@diegosouzapw one note on CI: release/v3.8.50 is red at the base right now (stale ESLint suppressions, unit shards, Fast Quality Gates), so those reds should appear on other PRs too and are not from this change.

Closes #11180