surface: don't gate the web UI on a provider key when the harness carries its own auth

[nimitbhargava]

Fixes #268

Heads up: CONTRIBUTING.md asks for text rather than code, so treat this as the report and take or discard the patch as you prefer. Happy to move it to an issue or an adrs/ note instead.

What happens

On HARNESS=claude with no ANTHROPIC_API_KEY / OPENAI_API_KEY / OPENROUTER_API_KEY configured, every web navigation 302s to /admin/onboarding and the web UI is unreachable. The only action offered there is pasting a provider key that the Claude Code harness never uses.

Why

getSurfaceConfig in src/api/routes/surface.ts computes the flag straight off stored credential availability:

...(managedKeys ? { modelProviderConfigured: Object.values(managedKeys).some(Boolean) } : {}),

plugins/portal/src/index.ts then redirects on modelProviderConfigured === false.

That check is harness-blind, and modelProviderAvailabilityFor in src/model/pi-models.ts already encodes the opposite for this harness — it returns ALL_PROVIDERS_AVAILABLE for claude because the CLI authenticates itself and never bills through a provider key. claude-harness.ts never reads providerKeys at all.

The change

Names that property once, derived from modelProviderAvailabilityFor so there's a single source of truth, and ORs it into the gate.

The gate can only widen. pi, opencode and codex all evaluate exactly as before, and the key-configured path is untouched. onlyProvider picks up the new constant to drop a duplicated literal.

Verification

npm run typecheck, oxlint, and prettier clean. 24 tests pass across pi-models, base-model-serviceability, webui-model-allowlist, and plugins/portal/test/onboarding-redirect (all 5 onboarding-redirect cases still pass, including "once a provider is configured, admin HTML navigation proxies to web-ui again").

Against a local dev instance on HARNESS=claude with no provider key: before, / 302s to /admin/onboarding; after, / serves the web UI, the composer shows the Claude Code harness with Opus 5, and the turn proceeds to the CLI's own auth (Not logged in - Please run /login), which is the expected next step rather than the gate.

I can attach before/after screenshots of the portal if useful.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[time-attack]

PR #128 appears to be the more precise harness-readiness fix because it requires actual harness-carried credentials. Please consider narrowing this PR to any distinct documentation or behavior not covered there, or superseding it after #128 lands. @16francej, can you choose the canonical path?

[time-attack]

Thanks for this, @nimitbhargava — and sorry for the slow response.

We're closing this PR. Per CONTRIBUTING.md, since coding agents write most of the underlying code now, we'd rather receive feature ideas as a short human-written note in adrs/ — informal is great, just the idea in your own words — and bugs as a plain issue. If we're aligned we're happy to burn our own tokens on the implementation, and we'll credit you as co-author.

We don't want your idea to get lost, so we've captured it in #805 to triage on our side. Please feel free to open an adrs/ note if you feel strongly about the approach. Appreciate you engaging with the repo!