[A3S Cloud/C0] Harden streaming, authorization metadata, and graceful drain

[ZhiXiao-Lin]

Cloud gate

C0 — stable control surfaces and team operations.

Planning reference: https://github.com/A3S-Lab/Cloud/blob/e2a05b7f1f63486b2fda866b22aa84eea89aadb4/docs/development-plan.md

Problem

Cloud uses Boot for long-lived API streams and process roles. C0 requires bounded streaming behavior, reliable disconnect cancellation, explicit authorization metadata, and graceful drain during upgrades.

Scope

• Propagate SSE and WebSocket disconnects into request cancellation.
• Add bounded queues, backpressure behavior, heartbeat policy, and slow-consumer termination.
• Define graceful drain for HTTP, SSE, WebSocket, worker, and relay roles with configurable deadlines.
• Make operation scope and authorization metadata visible in route definitions and generated OpenAPI.
• Provide a typed boundary for provider-backed distributed rate limiting without embedding a specific provider.
• Emit correlation and drain-state telemetry without request or credential contents.

Acceptance criteria

• Disconnect and slow-consumer tests leave no orphaned task, subscription, or socket.
• A draining process rejects new work, permits bounded in-flight completion, and terminates at the deadline.
• OpenAPI output carries the same scope requirements enforced at runtime.
• Multi-process rate-limit tests can use a shared provider through the public interface.
• Integration tests cover restart and shutdown for each Boot process role.

Non-goals

• Defining Cloud business permissions or membership rules.
• Implementing Cloud commands in Boot.
• Selecting a mandatory distributed rate-limit backend.

[ZhiXiao-Lin]

Status audit (2026-07-19): Boot #2 was human-merged as a5d631b with its Rust check green. It adds context-scoped providers, application enhancers, transport/WebSocket context propagation, and signal-aware lifecycle foundations.

That merge is useful infrastructure but does not satisfy this C0 issue. The merged tests do not yet prove bounded SSE/WebSocket queues, disconnect cancellation, slow-consumer termination, deadline-based drain for every process role, runtime/OpenAPI authorization-scope parity, a public distributed rate-limit provider contract, or correlation/drain telemetry. Keep the issue open until those behaviors have focused integration tests and CI evidence; the existing in-memory rate limiter and generic shutdown hooks are not substitutes for the requested multi-process and streaming guarantees.