bug(agents): login UI offers no API-key path for harnesses that accept one (kimi and others)

Problem

Harness settings > Kimi has one action: Login, which runs kimi login (browser authorize). A user with a Moonshot API key has no path to sign in from AO, and no guidance that the key route exists.

AO's own detector already accepts API-key auth for Kimi, so the login UI and the readiness check disagree about what counts as signed in.

Evidence

• Auth plans hardcode one flow per harness. backend/internal/service/agentauth/plans.go:20: kimi is plan("kimi", ActionLogin, ..., "Native browser flow") running kimi login.
• The Kimi auth detector treats API keys as authorized: backend/internal/adapters/agent/kimi/auth.go:31 accepts KIMI_API_KEY, OPENAI_API_KEY, KIMI_CODE_API_KEY, MOONSHOT_API_KEY, and auth.go:193 accepts a non-empty api_key in config.toml.
• Result: the detector can report a user "authorized" through a config the login UI never helps them create.

Repro

1. Settings > Harnesses > Kimi with no existing Kimi login.
2. Only button is Login. It opens the kimi login browser flow.
3. No API-key option or mention of one anywhere in the flow.

Scope

Not kimi-only. plans.go gives every harness exactly one fixed flow. Same gap for harnesses whose detector honors an API key but whose plan offers only native login: grok (XAI_API_KEY), cursor (CURSOR_API_KEY), droid (FACTORY_API_KEY), cline (CLINE_API_KEY), kimchi (KIMCHI_API_KEY).

Fix hint

Per-harness guidance naming the API-key path, using the documentationPlan pattern (plans.go:48) or enriched Guidance/DocumentationURL. A paste-key UI is a bigger change: clients never send credentials by design (service.go:1).

Source: Discord report-bugs thread, 2026-09-14, reported by .phylolver (vaibhaav) Analyzed against: 9bbd9b9e1 (origin/main) · Confidence: High