Design user-sponsored agent sessions for Apollo

## Background Refs #5573 and #5624. The first incremental step for agent-facing Apollo workflows is an official OpenAPI-based CLI. The more complex authorization model should be designed separately after the CLI surface and security expectations are clearer. This issue tracks the later design direction for user-sponsored agent sessions. ## Problem Existing OpenAPI automation is based on Consumer tokens. That works for scripts and platforms, but it is not a complete agent authorization model: - Consumer tokens may be too broad for AI-assisted workflows. - An agent can be affected by prompt injection or untrusted context. - Apollo configuration values may contain sensitive data. - Some operations should be proposed or approved rather than executed directly. - Audit should distinguish the sponsoring user, the agent/session context, and the actual operation. ## Direction Explore a user-sponsored agent session model: - A user explicitly creates or approves a bounded agent session. - The session is scoped to selected apps, envs, clusters, namespaces, and action classes. - Effective permission is the intersection of the sponsoring user's permission and the session scope. - High-risk operations require approval or are disabled by policy. - Sensitive reads are redacted, separately approved, or disabled depending on policy. - Audit records include user, session, agent/tool metadata, operation, target, and approval state. ## Possible scope dimensions - App scope: one or more app IDs. - Environment scope: selected envs only. - Namespace scope: selected namespaces or namespace patterns. - Action scope: read, diff/propose, config write, release, rollback, permission/admin. - Time scope: short-lived session expiration. - Approval scope: operations that require explicit user confirmation. ## Open questions - Should the first server-side model introduce an `Agent` principal, or only an `AgentSession` sponsored by a user? - How should Apollo classify sensitive config values for agent access? - Which operations can be executed directly, proposed only, approval-required, or disabled by default? - How should the CLI switch between Consumer token mode and future agent session mode? - Should MCP or other agent protocol adapters call Portal directly, or go through the same governed CLI/OpenAPI semantics? ## Out of scope for the first CLI release - Implementing the server-side session model. - Replacing existing Consumer token OpenAPI flows. - Providing MCP before the trust and audit model is clear. ## Acceptance criteria for this design issue - A concrete trust-boundary proposal is documented. - Scope and permission intersection rules are defined. - Sensitive-read and mutation approval defaults are defined. - Audit metadata requirements are defined. - Follow-up implementation issues can be split for `apollo-openapi`, `apollo-portal`, CLI integration, and protocol adapters.