Per-client resource quotas for the shared workspace runtime

[cf-pages]

Context

The 0.3.0 work (dual-era MCP support, removal of HTTP sessions) makes every authenticated client of a workspace share one Runtime instance. Several resource pools are global to the workspace and can be exhausted by a single client:

• Active command slots: MAX_ACTIVE_COMMANDS = 16 — one agent can starve another out of exec_command.
• Retained output: 32 entries / 16 MB per workspace, shared across clients.
• CommandRun output cursors: snapshot_since_cursor() consumes a single per-command cursor, so two clients polling the same command_id steal each other's output. This is pre-existing semantics from Share command runs across MCP sessions #34 (workspace-shared commands), not introduced by 0.3.0.

Why not now

• Prerequisite is a definition of client identity. The 2026-07-28 _meta.clientInfo is request-scoped and self-reported; a stable principal likely comes from the OAuth-workspace binding discussed in PR feat: add persistent OAuth, workspace-bound sessions, gateway, and Admin UI #35.
• No quota starvation has been reported in practice yet.
• Today's threat model is documented as: same workspace + same authentication = single trust domain.

Scope sketch

• Per-principal command slots and retained-output budgets.
• Per-consumer (or explicit-offset) output cursors instead of one global cursor per command.
• Document the fairness/trust model in SECURITY.md.