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.