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

## 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`.