Authenticate automation control-plane actions and workspace access

[jaydubya818]

Problem

PR #39 intentionally ships automation controls under a trusted-operator V1 deployment boundary because Mission Control does not yet expose a consistent authenticated operator identity and workspace-membership check across the application.

Today, actorId on candidate acceptance, activation, and pause is a client-asserted audit label. evaluateNow does not accept an actor label, but the public mutation still needs authenticated operator authorization. Workspace/entity mismatches fail closed; identity and membership are not independently verified.

Scope

• Establish the canonical authenticated Mission Control operator identity.
• Enforce workspace membership/role checks consistently for:
  • automations.acceptCandidate
  • automations.activate
  • automations.pause
  • automationScheduler.evaluateNow
• Derive decision attribution from trusted auth context rather than client input.
• Define and enforce the minimum role/capability for activation, pause, and manual evaluation.
• Preserve the existing separate acceptance/activation gates, LEVEL_1 read-only constraint, approval requirement, and scheduler idempotency.
• Migrate or explicitly label historical CLIENT_ASSERTED_TRUSTED_OPERATOR decisions without rewriting their audit meaning.
• Add denial tests for unauthenticated users, cross-workspace users, and insufficient roles.
• Update UI copy and audit presentation once actor attribution is verified.

Acceptance criteria

• Privileged automation mutations reject unauthenticated calls.
• The server derives actor identity; a client cannot impersonate another actor.
• Cross-workspace and insufficient-role calls fail closed.
• Decision records distinguish authenticated actors from legacy trusted-deployment labels.
• Existing automation governance and scheduler tests remain green.

Relationship

Follow-up to #39. This is intentionally separate from the bounded CI/package-boundary correction.