Configured credentialless providers require an empty API key

Description

In V2, Catalog.provider.available() treats any string-valued settings.apiKey, including an empty string, as an enablement signal. A provider explicitly added through config can therefore remain unavailable when it has no active Integration connection unless users set apiKey: "". The resolver then also interprets that empty value as a request to suppress native provider authentication.

Provider activation should be modeled independently from credentials. Configured providers should be explicitly enabled, automatic providers should derive availability from Integration state, and disabled providers should remain unavailable. For explicitly enabled API-key routes with no resolved or configured credential, Core should use Auth.none without replacing provider-owned auth such as Bedrock SigV4.

Steps to reproduce

1. Configure a custom Google or xAI gateway with a baseURL and custom authentication header.
2. Do not configure a provider API key or active Integration credential.
3. Observe that the provider is absent unless settings.apiKey is set to an empty string.

Plugins

None

OpenCode version

V2 development branch

Start by tracing V2 Catalog.provider.available() and the resolver paths described in the issue, then inspect how Core handles Auth.none and provider-owned authentication. Verify configured, automatic, and disabled provider states separately, including Google and xAI gateways without credentials. Done means explicit enablement no longer depends on an empty apiKey, and native authentication is preserved when no credential is resolved.