[Feat] Service accounts and an explicit API version

[haofeif]

Part of #777. After 3.0.

Service accounts build on #778's tenants, #774's stable identity/ownership and #779's membership/permission lifecycle. Audit attribution depends on #782. The public API versioning work is a separate part of this issue and can be designed independently.

In plain terms

Two gaps that only start to hurt once CAO is a shared service other things depend on.

CAO has no tenant-managed service accounts. Machine access already exists: the shared CAO_ELASTIC_BROKER_TOKEN authorises broker-management calls, and each worker gets a separately generated CAO_ELASTIC_RELEASE_TOKEN, checked against that worker's Deployment (examples/cao-clusters/kubernetes/eks/broker.py:1035-1079, :1265-1273). Those are different credentials with different authority; neither is a managed service account belonging to a tenant with its own role and account lifecycle. The missing capability is an independently managed automation identity, not an inability for machines to make authenticated calls.

The core HTTP API has no overall versioning and compatibility contract. Some surfaces are already versioned: AG-UI uses /agui/v1/stream, /agui/v1/emit_ui and /agui/v1/run (api/main.py:1709, :1968, :2117). The core session, terminal and workflow routes remain unversioned. Pipelines, scripts and other clients of a shared CAO upgrade independently, so this issue needs to define compatibility across those surfaces rather than assume no versioned endpoint exists.

What this delivers

Service accounts that belong to a tenant, with their own roles, usable for automation, and revocable without touching a person's account.

An automation account has its own stable identity and owned resources or explicit grants under the same tenant/visibility policy. Its creator, current caller and resource owner are not interchangeable. Define what happens to its queued/running work and retained data on revocation, reusing #779's bounded cancellation/cleanup rules where applicable.

Short-lived service-account credentials by preference. Independent account management is the new capability here. Restricted, task-bound agent credentials and request-scoped runtime identity are already required in 3.0 by #774/#745; they must not wait for this ticket.

An explicit API version and a compatibility promise — what may change without notice, what may not, and how long an old version is supported.

This is the later, overall public API contract. It does not postpone #745/#776's 3.0 server/runtime/MCP compatibility and upgrade requirements. Keep core HTTP API versions, MCP protocol revisions, terminal stream generations and database schema versions distinct; they solve different compatibility problems.

Acceptance criteria

• A service account can be created within a tenant, given a role, and revoked independently of any person.
• Its identity, permissions and retained ownership do not silently become those of its human creator; revocation has explicit queued/running-work and cleanup outcomes.
• Service account actions are attributable in the audit trail.
• Credentials are short-lived by default, with rotation documented.
• The API carries an explicit version.
• The compatibility promise is written down.
• Existing public clients have a documented transition/deprecation path. This work preserves rather than retroactively supplies the component/protocol compatibility needed by 3.0.
• On a laptop, none of this is needed and nothing changes.

Evidence

Claim	Where
No tenant-managed service accounts	Shared broker-management credentials and per-worker credentials already exist; neither supplies tenant service-account records and lifecycle
No overall core API versioning contract	Core session/terminal/workflow routes are unversioned; AG-UI already has /agui/v1 routes