[1.0] Qualify one authenticated API and dashboard access path

The existing authentication handlers are a starting point, but a supported access path must consistently bind authenticated callers to the identity and action permissions used by the API and dashboard.

Scope

• Qualify one existing API-key/Bearer access path for service clients and the dashboard using the current authentication component.
• Separate read permission from publish, invoke/control and destructive-operation permissions. Resolve identity once and reuse it in operation checks.
• Record authentication outcomes, denials and privileged actions without credentials or sensitive payloads; provide a complete configuration example.

Acceptance criteria

• A permitted caller, a read-only caller, an unrelated identity and an anonymous client receive the expected results for read and mutation operations.
• Identity cannot be selected or elevated through ordinary request payloads; the dashboard uses the same authorized operations as HTTP clients.
• Invalid credentials fail clearly, and audit records identify the actor and operation without exposing secrets.

Boundaries

OIDC/provider catalogs and sandboxing trusted in-process Python application code are outside this slice. WebSocket and other read-path enforcement have separate tickets under #280.

References

• Parent topic: #280.
• src/flock/components/server/auth/auth_component.py
• src/flock/orchestrator/server_manager.py

Start by reading src/flock/components/server/auth/auth_component.py and src/flock/orchestrator/server_manager.py to understand the existing authentication component and server access flow. Trace how API and dashboard operations resolve identity and permissions. Done means one supported access path meets the listed read and mutation cases, rejects identity selection or elevation, and records safe authentication and privileged-action outcomes.