feat(web): add Pi-native provider setup, reasoning controls, and OpenPI settings

[sowen1023]

Parent

• [Roadmap] OpenPI Web：像 Codex / Kimi Code 一样的本地浏览器 Agent 工作台 #76

Problem

The Web model picker can select an already available provider/model pair, but the browser cannot:

• inspect provider authentication availability without leaking credentials;
• start or complete a supported Pi-native provider login flow;
• view or set the current thinking/reasoning level;
• enter the canonical OpenPI setup episode;
• inspect package setup status or runtime provenance.

Users must leave the Web workbench to understand or change these settings, and unavailable models provide limited recovery guidance.

Value

• Make model configuration usable from the browser while keeping Pi authoritative.
• Preserve the single OpenPI setup entry point and typed persistence boundary.
• Give users enough provenance to diagnose which runtime/configuration they are operating.

Approach constraints

• Pi remains the source of truth for provider credentials, available models, and reasoning state.
• Credentials, tokens, and secrets must never enter snapshots, SSE events, browser storage, or logs.
• Model and reasoning changes bind to the expected Session and return exact accepted/stale/failed receipts.
• OpenPI configuration must continue through the canonical /openpi-setup episode and episode-scoped typed writer.
• Do not add a browser parser, direct preference-file writes, or an extension-specific setup command.
• Package-owned settings must keep setup config, status output, SETUP.md, README defaults, and tests synchronized.
• Authentication UI must use a reviewed Pi/provider seam; unsupported providers get explicit external instructions.

Acceptance criteria

• Web reports bounded provider/model availability and authentication status without secret material.
• Supported provider login uses Pi-owned authentication and reports success, denial, expiry, and failure.
• Users can inspect and change the thinking/reasoning level supported by the selected model.
• Model plus reasoning updates are atomic for the expected active Session.
• Web exposes the canonical /openpi-setup flow rather than a second configuration path.
• No-argument setup status and Web status agree on package-owned values.
• A read-only diagnostics view shows OpenPI version, checkout/package source, Pi version, active Session source, and relevant bounded capability provenance.
• Reconnect cannot repeat a login or configuration write.
• Tests prove secrets never enter serialized protocol state.
• Setup/config documentation and drift guards are updated.
• bun run check and bun run test pass.

Related work

• docs(routing): define provider/model selection, fallback, reasoning state, and invocation evidence #195 defines provider/model/fallback/reasoning state and invocation evidence.

Out of scope

• A second provider stack.
• Browser-managed credential storage.
• Hardcoded default providers or models.