The previous review flagged that providerHasCredentials misclassifies
working config-defined providers: Provider.key is only set by upstream
when exactly one declared env var resolves or an api-type auth.json
entry exists. Config providers only get options, so provider.<id>.
options.apiKey never reaches key. Result: a provider whose key is
embedded in opencode.json showed 'Credentials missing', lost the
Models section, and forced the auth panel open.
Add optionsApiKey to ProviderCredentialInput and check it in
providerHasCredentials alongside key and authSourceExists. This
matches what main's requiresProviderAuth helper used to do and
honors the OpenChamber docs contract that options.apiKey counts as
a usable login (walkthrough/DOCUMENTATION.md:134).
Wire the new field through ProvidersPage.tsx using a typed
indirection: the SDK Provider type does not yet expose options
publicly, so the read site casts the object to the known shape.
This keeps the call site type-safe without waiting for an SDK
update.