fix(metrics-auth): DisableLogin no longer opens /metrics; log correlation pair; host-level tests

- The metrics scheme skips its dashboard-cookie fallback while
  Dashboard:DisableLogin is on, so the dev auto-login handler cannot
  satisfy RequireAuthentication=true.
- Invoke logs client_correlation_id <-> worker envelope id once at Debug.
- MetricsEndpointAuthenticationTests drives the real pipeline: anonymous
  loopback 401 (no /login redirect), Viewer cookie 200, admin key 200,
  non-admin key 403, DisableLogin 401, /health/active 200.
- Docs: DisableLogin behaviour; the /metrics limiter partition is per IP
  vs gRPC per connection, so only the per-key aggregate is shared.

docs/DesignDecisions.md

@@ -456,10 +456,13 @@ stays anonymous unconditionally.
   values.
 - **No environment bypass.** The requirement reads no options, so anonymous
   localhost and `Authentication:Mode=Disabled` — both of which satisfy the
-  dashboard Viewer policy — do not satisfy it. Only dev-only
-  `Dashboard:DisableLogin` (which authenticates every request as an
-  Administrator, and is rejected in Production) lets an unauthenticated scrape
-  through.
+  dashboard Viewer policy — do not satisfy it. Nor does dev-only
+  `Dashboard:DisableLogin`: its auto-login handler sits under the cookie scheme
+  name, so the metrics scheme skips the cookie fallback while it is on rather than
+  letting a dev flag silently open an endpoint the operator asked to protect.
+- **Throttle sharing is partial.** The `/metrics` per-peer limiter partition is
+  the remote IP, while the gRPC one is the gRPC peer string (per connection), so
+  only the per-key-id aggregate is shared between the two paths.
 - **One scheme, plain 401.** Listing the cookie scheme on the policy directly
   would challenge an anonymous scrape with a 302 redirect to `/login`; a single
   scheme that falls back to the cookie internally keeps the challenge a `401`