Document stream rate limiting, keepalive, and max duration expectations

[lanycrost]

Problem statement

All four bidirectional streaming RPCs (Data, Control, HubPush, Process) have no contract-level guidance on flow control enforcement, maximum stream duration, keepalive intervals, or message rate limiting. While FlowControl messages exist for backpressure, their use is optional and the protocol allows indefinite streams with no idle detection.

Without documented expectations, implementations may:

• Accept unlimited concurrent streams (connection-level DoS)
• Never close idle streams (resource leak)
• Ignore FlowControl signals (backpressure failure)

Proposed change

Add stream lifecycle documentation to proto comments on each service:

// TransportConnectorService is the connector-side transport contract.
//
// Stream lifecycle expectations:
//   - Connectors SHOULD send keepalive pings at least every 30s on idle streams.
//   - Implementations SHOULD close streams idle for more than 2 minutes.
//   - Implementations SHOULD enforce per-stream message rate limits to prevent
//     flood-based resource exhaustion.
//   - FlowControl.credits_messages and credits_bytes SHOULD be honored by
//     producers; ignoring flow control may result in stream termination.
service TransportConnectorService { ... }

Consider adding a StreamConfig message for machine-readable hints:

message StreamConfig {
  uint32 max_duration_seconds = 1;
  uint32 idle_timeout_seconds = 2;
  uint32 max_messages_per_second = 3;
}

Affected area

• Proto definitions

Compatibility / migration

Comment-only changes have no wire impact. Adding StreamConfig as an optional message is additive and backwards-compatible.

Additional context

Identified during security review. The attack scenario is an attacker opening thousands of Process streams with minimal traffic to exhaust hub connection/goroutine limits while legitimate clients are rejected.