Admin UI authentication: documented proxy pattern + optional built-in token auth

[hardbyte]

Problem

The admin UI ships with a --read-only / AWA_READ_ONLY=1 mode, and the deployment docs' stance is "put it behind your ingress/proxy". That stance is defensible, but today it's implicit — there is no documented worked example, and no authentication option at all for teams without an auth-capable ingress. The UI exposes retry, cancel, DLQ purge, batch operations, cron pause, and storage-transition controls: mutating, operator-grade actions.

Proposal (smallest useful slice first)

1. Document the proxy pattern properly: a worked oauth2-proxy (or equivalent OIDC proxy) example in front of awa serve, alongside the existing managed-Postgres sidecar examples, plus an explicit "never expose the UI directly" statement in docs/security.md.
2. Optional built-in authn: a minimal static-token / basic-auth option (AWA_ADMIN_TOKEN) for teams without ingress auth — enough to not be open-by-default on a cluster-internal network, explicitly not an SSO replacement.
3. Authz granularity (later, maybe): today the only role split is read-only vs everything. A middle tier (e.g. retry/cancel allowed, purge/storage-transition denied) may be worth it once 1–2 exist; deliberately out of the first slice.

Whatever ships must hold for the embedded-UI path (awa serve, python -m awa serve) and the callback-only router (#293) should document its own ingress posture by contrast — callbacks are already BLAKE3-signed (ADR-018/ADR-027).

Refs: ADR-027, #293, docs/security.md, docs/deployment.md.