08baf96537
Fixes #86864. Legacy custom_providers configs commonly used short/placeholder api_keys ('123', 'm') for local no-auth services like Ollama -- harmless for the endpoint itself, since Ollama accepts any key or no key. A stricter has_usable_secret(value, min_length=4) gate added later now rejects these, but only the credential-POOL resolution path lacked the same "no-key-required" exemption every OTHER resolution path in this file already has for exactly this scenario: - The config-based custom_providers fallback (non-pool path) already ends with `api_key or "no-key-required"`. - The "actual" provider's local-offline path already injects ACTUAL_LOCAL_NOAUTH_PLACEHOLDER before the usable-secret gate for a loopback base_url. - _try_resolve_from_custom_pool() was the one gap: it returned the raw short pool credential unchanged, which then failed the downstream has_usable_secret() gate with a generic "No usable credentials found for custom" error that contradicts setup.status ("configured credentials" vs "runtime failed"), sending users hunting in the wrong direction. Fixed by substituting the same "no-key-required" placeholder when the pool's stored credential fails has_usable_secret() AND the base_url resolves to a loopback hostname (using the existing _loopback_hostname helper, matching the exemption scope the issue itself requested: localhost/127.0.0.1/::1 only, not arbitrary remote endpoints with a genuinely-too-short key). Added 4 regression tests extending the existing test_runtime_provider_resolution.py file, following its established credential-pool mocking pattern: the exact reported 3-char repro ('123'), a 1-char case, a non-loopback sanity check confirming the exemption stays scoped (a short key for a remote endpoint is NOT silently exempted), and a sanity check that a genuinely usable loopback key passes through unmodified. Verified as a genuine regression by reverting the fix and confirming 2 tests fail with the exact raw short key leaking through unchanged. 59/59 pass in the extended test file; 14/14 across two more related custom-provider test files (no regression).