Observability: put Phoenix behind authentication (Keycloak OIDC), restrict playground access #90

Related to #80, #32, #33.

Context

Phoenix becomes more important under the workflow-configuration epic: it's where admins review traces tagged with workflow versions and eval runs. It also becomes more powerful:

• Its playground can make direct calls to the model, bypassing EAIStack's guardrails, rate limiting and audit.
• Its traces contain user prompts and responses, the same sensitive content as conversation_threads.

Today, anyone who can reach the Phoenix UI gets both. The Dashboard links out to it (tracing_ui_url) with no access control on the Phoenix side.

Scope

1. Evaluate Phoenix's built-in authentication and whether it can use Keycloak OIDC, so access is limited to EAIStack admins through the same identity provider. If Phoenix's own auth can't use OIDC, consider an OIDC-aware reverse proxy in front of it.
2. Decide whether playground access should be restricted further than trace viewing, or disabled.
3. Document the access model in docs/OBSERVABILITY.md and docs/SECURITY.md.

User-visible signal

Opening Phoenix requires a Keycloak login with the admin role; a non-admin gets an access-denied page.

RBAC

Admin feature.

Relates to

#33 (TLS for Phoenix), #32 (trace retention). Together these three are prerequisites for relying on Phoenix in the workflow iteration loop.