Move provider state into provider bridge contract

[ymichael]

What was wrong

Provider readiness, usage, installation, and update state was assembled in onboarding/server/daemon code even though generic product paths—including the root composer and Settings—also depend on it. That mislabeled shared provider behavior as onboarding behavior and forced every provider-specific maintenance change into core host and server code.

What changed

• Added experimental, sessionless provider bridge methods for provider/health, provider/usage, provider/installation/status, and provider/installation/run.
• Moved Codex, Claude Code, and Cursor installation discovery, source/version checks, executable plans, and post-run verification rules into their provider bridges. Provider registration explicitly declares whether installation is supported.
• Kept the daemon as the host execution boundary: it supplies the host environment and cwd, serializes installs, supervises and streams the process, re-reads provider status, and rejects an install/update that the provider cannot verify. Executable arguments remain host-local; product clients receive only the display command.
• Replaced hard-coded install/update provider enums with registered provider IDs and registry/host ordering across the server, app, CLI, and mobile. Providers without the installation capability are omitted.
• Replaced onboarding-specific provider state APIs with generic provider state aggregation used by onboarding and unset root-composer selection. Usage settings now use the registration capability to avoid probing or rendering unsupported providers.
• Bumped HOST_DAEMON_PROTOCOL_VERSION to 139 for the provider-scoped installation RPCs and documented the experimental plugin/bridge contract in docs/api_to_audit.md and docs/provider-bridge-protocol.md.

How you verified

• Rebasing onto current origin/main completed without conflicts.
• Turbo typecheck passed across the 12 affected packages (16 tasks), including all provider plugins, protocol/contracts, daemon, server, app, CLI, and mobile.
• Focused provider-installation tests passed in the Codex, Claude Code, and ACP bridges; daemon execution/verification passed 30 tests; host-daemon contract passed 52 tests; server aggregation/registration passed 11 tests.
• App install/update/onboarding inventory passed 53 tests; CLI passed all 454 tests; mobile inventory passed 13 tests; runtime bridge mapping passed 19 tests; plugin SDK validation passed 42 tests.
• App and mobile lint completed with zero errors, and git diff --check passed.

Related to #1620

AGENT GENERATED: by GPT-5

[bb-slop-cop]

🚨 SLOP COP 🚨 · review

I am SlopCop. I am reviewing this pull request for security, quality, performance, architecture, duplication, and end-to-end behavior.

[bb-slop-cop]

🚨 SLOP COP 🚨 · review

Plain English summary: This change lets each AI provider report its install, sign-in, version, health, and usage state through one bridge contract. The server uses those reports in onboarding, the composer, Settings, the SDK, and the CLI.

I found two P1 issues and three P2 issues:

• P1: The committed SDK and template declarations are stale. This mismatch now makes the package test and check jobs fail.
• P1: A fresh machine can hide all provider install choices when Pi reports unauthenticated. The user cannot install a usable provider in onboarding.
• P2: Plugin bridges can show Install or Update buttons without a matching host action.
• P2: The server accepts plugin usage reports, but Settings shows only three fixed providers.
• P2: Provider state and usage checks start unlimited parallel work. The maintenance runtime also keeps each bridge process until shutdown or invalidation.

The security review found no security issue. The host daemon protocol version has the correct change from 135 to 136.

I started the development app and tested the changed user paths. Provider state and usage routes returned HTTP 200.

The composer selected a ready provider. Usage Settings showed Codex, Claude Code, and Cursor data. Onboarding showed seven providers and advanced to project selection.

The first provider state and usage requests each took about 11.5 seconds. One request left seven bridge workers after the page closed.

The provider bridge test groups passed 672 tests. The focused runtime tests passed 14 tests. The server, host daemon, and app type checks passed.

git diff --check passed. The current GitHub package test and check jobs fail because the generated declarations are stale.

I also checked for repeated code and possible shared helpers. I found repeated executable, version, percentage, and credential helpers across provider packages.

These helpers are small. Provider isolation makes a shared module optional, so I did not report this repetition as a defect.