Add additional scaffolding

[mdeyell-valid-mind]

Summary

• add an optional access resolver for embedding-application authorization
• map verified operator identities to capabilities and assigned agent CUIDs
• scope review invocations, plans, agent-scoped rules, and agents to the caller's assignments
• allow assigned users to approve, deny, and summarize their own invocations
• require runtime agent identities to resolve to a stored Atryum agent when authority mode is enabled
• record the resolved actor on invocation and plan decisions
• preserve unrestricted operator access for trusted static API-key credentials
• bind email-less OAuth runtime tokens to the exact stored agent CUID instead of granting user or unrestricted access
• store stable agent ownership on invocations, plans, and external sessions
• scope invocation idempotency keys by stable agent CUID
• expose summary availability without exposing administrative settings
• support local invocation summarization without requiring a ValidMind backend client

Access model

Embedders can enable the new behavior with atryum.WithAccessResolver.

For human operator tokens, the resolver maps a verified token email to:

• an opaque actor ID
• assigned agent CUIDs
• read_resources
• update_agents
• decide_invocations
• summarize_invocations
• decide_plans
• administrative_operations

Static operator API-key credentials remain unrestricted. Runtime OAuth tokens follow a different path: an email-less client-credentials token must carry an agent identity that resolves to a stored Atryum agent, and the caller is bound only to that agent's CUID. A runtime token with an email must also resolve to a provisioned user assigned to that agent.

Without an access resolver, Atryum continues to use its existing authentication and authorization behavior.

Scoped resources and decisions

Scoped operators can:

• list and inspect invocations and plans owned by assigned agents
• approve or deny assigned invocations
• summarize assigned invocations using the administrator-configured model
• approve, deny, or request revisions to assigned plans
• read assigned agents and update permitted agent fields
• read global rules and agent-scoped rules that overlap their assignments

Administrative operations remain restricted. In particular, scoped users cannot create approval rules while deciding an invocation or override the configured summary model.

Invocation summarization

The PR adds GET /api/v1/invocation-summary/config, an authenticated endpoint that returns only whether invocation summarization is available. This lets the invocation UI enable summarization for assigned users without reading or exposing administrative settings.

Summary availability and execution now treat the configured providers independently. A configured local summarizer works without a ValidMind backend client.

Agent ownership

Invocations, plans, and external sessions now persist agent_cuid alongside the runtime agent_id.

The stable CUID is used to:

• restrict resources to assigned agents
• match plans across multiple runtime agent IDs
• scope idempotency keys per agent
• retain ownership when runtime aliases change

Migration 030 adds the ownership columns and supporting indexes, and backfills agent_cuid on existing rows from the agents table. Any lookup that keys off the stable CUID (plan-pass matching, idempotency-key scoping) falls back to the agent_id/alias lookup whenever the CUID lookup finds nothing, so a row with no resolved CUID never loses ownership.

Verification

• go test ./...
• go vet ./...
• git diff --check

Compatibility

• one authenticated route is added: GET /api/v1/invocation-summary/config
• agent_cuid is an additive field on invocation and plan API representations
• operator and runtime authorization behavior changes only when an access resolver is configured
• static operator API-key credentials remain unrestricted
• runtime client-credentials tokens remain agent-scoped and are not treated as unrestricted users
• idempotency keys are unique per stable agent CUID; legacy unowned rows retain uniqueness among other unowned rows
• migration 030 backfills agent_cuid on existing rows and falls back to the agent_id/alias lookup for any row where it's still unset, so in-flight invocations, approved plans, and idempotency retries survive the cutover