Switch supervisor->gateway communication to event-based streaming over supervisor sessions

[pimlock]

Summary

After OS-86 introduces the persistent supervisor->gateway session and uses it for SSH connect and exec, migrate the remaining supervisor->gateway communication onto that session using event/message traffic instead of separate unary or client-streaming RPCs.

This issue is no longer responsible for introducing the stream itself. It assumes the session transport already exists and focuses on switching existing communication patterns onto it.

Scope

Migrate existing supervisor->gateway traffic such as:

• GetSandboxConfig polling
• GetSandboxProviderEnvironment
• PushSandboxLogs
• ReportPolicyStatus
• SubmitPolicyAnalysis
• Inference.GetInferenceBundle polling
• any retained sandbox->gateway policy sync behavior

The goal is to replace these separate RPCs with session messages, snapshots, updates, acknowledgements, and reports on top of the existing supervisor session.

Design topics

This work is expected to need a design document or RFC because it touches questions like:

• message ordering
• event/message granularity
• acknowledgement semantics
• retry and replay behavior
• desired-state vs event semantics
• how much behavior remains pull-driven versus fully push-driven

Non-goals

• introducing the persistent supervisor session transport itself
• replacing SSH connect or ExecSandbox again
• exposing long-running services through the gateway
• fully solving multi-replica lease ownership beyond what the session substrate already provides

Acceptance criteria

• the remaining sandbox->gateway control traffic no longer depends on separate per-feature RPCs where the session equivalent is adopted
• config, policy, logs, analysis, and inference route delivery use the supervisor session message model
• message ordering, ack, and failure semantics are documented clearly enough for implementation and operations
• legacy RPCs that become redundant can be deprecated or removed once migration is complete