feat(supervisor): push gateway desired state

[pimlock]

Summary

Implement issue #1731 in one PR. Replace supervisor polling for gateway-owned desired state with bootstrap and correlated ConfigUpdate snapshots over ConnectSupervisor.

This PR is a draft while the protocol, startup ordering, update application, reconciliation, polling removal, tests, and documentation are completed.

Related Issue

Closes #1731

Planned Changes

• Rename the existing config, provider-environment, and inference response messages as reusable snapshot types.
• Carry a complete bootstrap in SessionAccepted and gate initialization on its result.
• Deliver later component snapshots through correlated, sequenced ConfigUpdate messages.
• Add bounded owner reconciliation and immediate invalidation.
• Preserve standalone and local-override behavior.
• Remove obsolete supervisor polling and internal provider/inference fetch RPCs.
• Update architecture and compatibility documentation.

Excluded

Changing deployment defaults for supervisor:latest is not part of this PR.

Testing

Work in progress. Final verification will include focused protocol/runtime tests, mise run pre-commit, mise run test, relevant sandbox E2E coverage, and mise run ci.

Checklist

• Implementation complete
• Documentation updated
• Pre-commit passes
• Unit and integration tests pass
• Relevant E2E coverage passes
• Full CI passes

[github-actions]

🌿 Preview your docs: https://nvidia-preview-pr-2967.docs.buildwithfern.com/openshell

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[pimlock]

/ok to test 1ab15bf

[lbelyaev]

The bootstrap-gates-initialization model is a real improvement over the fetch-and-continue path — requiring provider_environment in ConfigBootstrap closes the empty-start-on-fetch-failure case cleanly.

One thing worth surfacing while the readiness semantics are still open: handle_result classifies ConfigApplyOutcome::Degraded as terminal_success, so a provider-environment component that applies Degraded still advances applied_revision and lets the session reach initialized/ready — the same path a clean Applied takes. Failed/Unsupported are correctly excluded, so the intent to proceed-on-degraded looks deliberate. The gap is that once it's folded into applied_revision, nothing downstream can distinguish a fully-applied provider environment from a degraded one: a consumer gating on Ready (or on the applied revision) sees success in both cases.

Would it be worth carrying the per-component outcome through to an observable signal — either surfacing provider_environment_outcome alongside the applied revision, or a readiness condition that only holds when the provider environment applied Applied (not Degraded)? For anything that needs provider credentials in place before it dispatches, "Ready" currently can't express "Ready, but provider state is degraded," and a bounded pre-dispatch retry is the only client-side workaround. A deterministic E2E that asserts a Degraded provider apply is visibly distinguishable from Applied would pin it.

[pimlock]

Superseded by #3244, which implements Stage 1 of the revised rollout for #1731. The gateway sends full configuration snapshots while supervisor polling remains authoritative. Stage 2 will apply snapshots and acknowledge revisions; Stage 3 will add durable completion semantics and remove polling. Closing this all-in-one draft in favor of the staged implementation. Replacement: #3244