fix(relay): require credentials for deployment admin access

[jmecom]

This change requires HTTP Basic credentials for every deployment admin route: the
dashboard, the admin SPA bundle it loads from BUZZ_ADMIN_WEB_DIR, the admin APIs,
reports, feedback, and attachments.
Unauthenticated requests get 401 with WWW-Authenticate: Basic realm="buzz-admin",
so browsers hitting the dashboard now see a credential prompt.

The existing Host and Origin checks remain as boundary checks, but they no longer
act as the administrator credential.

Configuration

Variable	Required	Rule
BUZZ_ADMIN_PASSWORD	yes, when BUZZ_ADMIN_HOST is set	16–1024 bytes, no control characters
BUZZ_ADMIN_USERNAME	no, defaults to admin	≤128 chars, no colon, no control characters

The colon ban matters: the digest covers username:password, so without it
("oper:ator", "secret") and ("oper", "ator:secret") would authenticate as each
other. Passwords may contain colons.

The runtime keeps only a SHA-256 digest and compares it in constant time
(subtle::ct_eq); a hand-written Debug impl redacts it. just admin generates
and prints a random dev password when one isn't set.

Rollout

squareup/bb-public sets BUZZ_ADMIN_HOST=admin.buzz.xyz in production with no
password configured. An earlier revision of this PR aborted startup on that
config, which would have crashlooped the entire relay fleet — websocket, media,
git — over an optional dashboard.

The relay now logs an error and disables the dashboard instead, so the image
is safe to ship in any order relative to the config change. admin = None means
is_admin_host() is false, the admin router is never mounted, and authorize()
returns not_found — nothing admin-scoped is reachable, and the admin SPA bundle is
never served because web_dir lives on the AdminConfig that is now absent.

In that state the admin host is treated like any unmapped host. It is not a community
subdomain, so bind_community() fails and both browser requests and WebSocket upgrades
get 404 relay: no community is configured for this host. Three things do stay
reachable there without credentials, as they are on every host: the NIP-11 document
(fail-open by design), /assets/* from BUZZ_WEB_DIR (the public web bundle, not the
admin one), and the /invite/<code> SPA shell — which returns the same bytes for every
code and so is not an enumeration oracle.

Consequence: admin.buzz.xyz goes dark on deploy until BUZZ_ADMIN_PASSWORD
reaches the pod. To restore it, follow the BUZZ_GIT_HOOK_HMAC_SECRET pattern in
squareup/bb-public:

1. Add /services/buzz/service-secrets/admin-password to AWS Secrets Manager (us-west-2)
2. Map it to secretKey: BUZZ_ADMIN_PASSWORD in externalsecret-buzz-secrets.yaml
3. Add the matching secretKeyRef env entry to the chart's deployment template —
   the chart wires keys individually, there is no envFrom

Watch startup logs for admin dashboard disabled to confirm state either way.

Testing

• cargo clippy -p buzz-relay --all-targets -- -D warnings — clean
• cargo fmt --check — clean
• cargo test -p buzz-relay --lib — 833 passed; the 10 failures are pre-existing
  and infra-dependent (no local Postgres/Redis), an identical set to main
• Not run locally: integration suite (just test)

Originating Buzz thread: buzz://message?channel=3928fe05-df61-4b5d-b9c7-d623b9b10ea1&id=3c6c02312f763fbe0d2bfc33a6c1a362f91d0354f3d18b039cf7a0558c1439d1