[FEATURE]: Add Kiro (kiro.dev) as a selectable provider

[Sebuahhobi]

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Kiro now supports API-key based authentication for Kiro CLI headless / non-interactive usage via the KIRO_API_KEY environment variable.

OpenCode already supports adding provider credentials through /connect, and it would be useful to have Kiro available as a first-class selectable provider there, instead of requiring custom configuration or third-party plugins.

Requested behavior:

• Add Kiro to the selectable provider list in /connect.
• Support reading credentials from KIRO_API_KEY.
• Optionally allow users to paste a Kiro API key through /connect, similar to other providers.
• Expose supported Kiro models in /models, such as Auto and the models available from Kiro CLI/model metadata.
• Document that Kiro API key authentication is currently for Kiro CLI headless usage and may require a Pro/Pro+/Power subscription and/or admin-enabled API keys.

References:

• Kiro CLI headless mode uses KIRO_API_KEY.
• Kiro API keys can be generated from the Kiro web console for supported plans.
• OpenCode supports adding provider credentials via /connect.

[HerShin5]

+1 on treating Kiro as a first-class provider instead of forcing custom config.

A minimal path that would be useful:

• provider entry in /connect
• env fallback via KIRO_API_KEY
• conservative /models list until Kiro exposes stable metadata
• docs note for plan/subscription/API-key availability

For testing, it might also help to keep the implementation provider-agnostic enough that people can validate against a hosted Kiro-compatible/API-backed endpoint as well as local CLI headless mode. Disclosure: I’m involved with https://kiroforge.cloud, which could be useful as one optional test target, but the OpenCode integration should definitely stay cleanly configurable rather than tied to any specific service.

[ruanmed]

Just a FYI, current PRs open that would solve this feature request: #9164 and #20491