docs(admin): scope Audit middleware coverage to the protected chain

Codex P2 on the latest review of #674: the audit-log section
said the Audit middleware "is emitted for every non-GET/HEAD/
OPTIONS request that reaches the admin mux on this node,
regardless of which handler served it." That overstates coverage:

- `/auth/login` is wired through `publicAuth`, not `protect` —
  the middleware can't identify the actor without a pre-existing
  session, so it is intentionally skipped. AuthService emits
  `admin_audit action=login` directly (auth_handler.go:432).
- `/auth/logout` is wired through `protectNoAudit` — the
  middleware is omitted to avoid emitting two audit lines per
  logout (a generic one plus the action-specific one); the
  specific line is the one operators want (auth_handler.go:442).
- The `protect` chain is `BodyLimit → SessionAuth → Audit →
  CSRFDoubleSubmit → handler` (server.go:247-255). Audit only
  fires AFTER SessionAuth accepts the session, so an
  unauthenticated write attempt (missing / expired / invalid
  cookie) gets 401'd before reaching Audit and produces no
  middleware line. CSRF-rejected requests still produce one,
  by design, because the actor is known by then.

An operator building log-monitoring on top of the previous text
could conclude that every write attempt is guaranteed to
appear in `admin_audit`, then miss CSRF-bypassing probes
against an unauthenticated endpoint.

Rewrote the middleware-shape section to:
- Scope the rule to the protected mux chain.
- Explain the ordering choice (Audit between SessionAuth and
  CSRFDoubleSubmit) so the CSRF-rejection-still-audits guarantee
  is preserved in the doc.
- Enumerate the two auth endpoints that bypass the middleware
  and what they emit instead.
- Adjust the intro paragraph: protected-chain mutations produce
  two audit lines, auth endpoints produce one (was: "every
  state-changing request typically produces two").

No behaviour change; doc-only. Verified against
internal/admin/server.go:236-296 and
internal/admin/auth_handler.go:432-449.

Author: bootjp

docs/admin.md

@@ -193,17 +193,37 @@ logs first.
 
 Every state-changing admin request emits structured slog lines at
 `INFO` level under the `admin_audit` key on the leader's stdout (or
-wherever the process slog handler is wired). A single state-changing
-request typically produces **two** audit lines: one operation-specific
-line from the source that performed the mutation, plus one generic
-HTTP-shaped line from the `Audit` middleware. The shapes differ by
-source — log parsers should treat the `admin_audit` key as a union
-and dispatch on the fields present.
-
-**`Audit` middleware** — emitted for every non-GET/HEAD/OPTIONS
-request that reaches the admin mux on this node, regardless of which
-handler served it. Always present on the node that received the HTTP
-request (which may be a follower if the request was then forwarded):
+wherever the process slog handler is wired). A protected-chain
+mutation (Dynamo / S3 / cluster / keyviz writes) typically produces
+**two** audit lines: one operation-specific line from the source
+that performed the mutation, plus one generic HTTP-shaped line from
+the `Audit` middleware. Auth endpoints (`/auth/login`, `/auth/logout`)
+produce **one** line — the action-specific one from `AuthService` —
+because the generic middleware is intentionally not wrapped around
+them (see the per-shape section below for why). The shapes differ
+by source — log parsers should treat the `admin_audit` key as a
+union and dispatch on the fields present.
+
+**`Audit` middleware** — emitted for non-GET/HEAD/OPTIONS requests
+on the **protected mux chain** (Dynamo, S3, cluster, keyviz) after
+`SessionAuth` accepts the session, but **before** `CSRFDoubleSubmit`
+runs. That ordering is deliberate: a CSRF-rejected protected
+request still produces an audit line because the actor is already
+known, but an unauthenticated request (no / invalid session) is
+rejected at `SessionAuth` and never reaches the middleware. The
+following endpoints are **not** wrapped by this middleware and rely
+on their own `admin_audit` emission instead:
+
+- `/auth/login` — runs without a pre-existing session, so the
+  generic middleware cannot identify the actor; `AuthService`
+  emits `admin_audit action=login` (success and failure) directly.
+- `/auth/logout` — runs through `protectNoAudit` so logout produces
+  exactly one `admin_audit action=logout` line from `AuthService`
+  rather than two (a generic line plus the action-specific one).
+
+For requests that *do* reach the middleware, the line is always
+present on the node that received the HTTP request — which may be
+a follower if the request was then forwarded:
 
 ```
 admin_audit actor=AKIA_ADMIN role=full method=POST path=/admin/api/v1/buckets status=201 remote=10.0.0.7:51234 duration=8.2ms