No-auth / keyless providers (opencode, opencode-zen) returned synthetic
"noauth" credentials BEFORE honoring excludeConnectionIds, so the chat
account-fallback loop re-selected the same synthetic connection forever on
a persistent upstream error (e.g. the opencode public endpoint answering
401 "Model X is not supported"). The synthetic id has no DB row, so
markAccountUnavailable could not persist a cooldown to brake it — each
iteration wrote key-health + request logs immediately, growing the DB until
the disk filled (see @paraflu's "failure #320" trace in discussion #3038).
Honor the exclusion set in both synthetic-credential paths
(getProviderCredentials NOAUTH_PROVIDERS block + opencode-zen keyless
fallback): once "noauth" is already excluded, return null so the handler
stops after a single attempt. The happy path (nothing excluded -> synthetic
noauth) is preserved, so keyless access still works.
Closes#3061.
Tests (TDD): tests/unit/auth-noauth-fallback-loop-3061.test.ts — the two
exclusion cases failed before the fix and pass after; two happy-path guards
ensure first-selection synthetic noauth still resolves.
