Per-caller authentication on the MCP endpoint

[plusky]

Depends on #27 and is blocked on the MCP authorization specification.

Today an HTTP client authenticates to Bugzilla, not to bugwarden: it presents a
Bugzilla API key per request and the server has no notion of caller identity of
its own. Once the server holds the key instead (#27), that incidental identity
disappears — clients present nothing, and any client that can reach the port is
served. The network boundary becomes the only access control, and audit records
can attribute a call to a session and a source address but not to a caller.

The audit schema already reserves the slot for the answer: ClientInfo.principal
is defined, documented as always None for now, and explicitly must never be
filled from anything the client declares about itself.

Why this is not just "add bearer tokens"

Static shared tokens were considered and declined for v1: they push key
distribution and rotation onto the operator, and a shared token authenticates a
deployment rather than a caller, which is not enough to make principal
meaningful in an audit record. The MCP authorization specification (OAuth 2.1
resource servers with scopes) gives per-caller identity and revocation as a
protocol feature; implementing an interim scheme now would mean shipping and
then deprecating an auth surface on a security boundary.

Until then the deployment guidance stands: reach the endpoint only from an
isolated network.

What this unblocks

• Filling principal in audit records with a verified identity, so the log can
  answer "which caller" and not only "which session".
• Per-caller policy, if we ever want the guard's capability set to vary by
  caller rather than being one server-wide policy.

Acceptance criteria

• Identity is verified by the server; nothing self-declared is ever
  promoted into principal.
• An unauthenticated request is refused uniformly, with no signal about
  whether a bug, tool, or policy exists (I2).
• Refusals are recorded.

---

See also #34 §4(g) — the 2026-07-28 revision does not change this: its authorization work is all client-side registration, so principal stays reserved and always None.