Document the auth boundaries and record LB-D4

Summary

Answering "where does this auth concern belong?" currently means reading &4, &3, and a handful of other issues, so it was a good candidate for writing a position down.

docs/design/auth-boundaries.md

Separates the four concerns with a clear owner and an outcome:

Concern	Question	Owner
Transport identity	Which process is calling?	Platform/mesh; chassis composes LabKit TLS
Request provenance	Did this come through GATE?	Chassis inbound + LabKit module
Service authorization	Is the calling service allowed?	Unassigned Related slack discussion
User authorization	May Principal X do Thing Y?	GATE, out of process

Row 3 is the find. Artifact Registry presents a GATE service token alongside the end-user JWT it exchanges against the issuer JWKS; gate-iam requires both on every non-Health RPC. So it is a real pattern in deployed services that the schema cannot express and it is distinct from both transport identity and URT provenance. Recorded as unassigned.

Two more unowned edges, both surfaced by Lore's adoption. GATE confirmed that anonymous callers get a URT, so public endpoints stay inside the provenance check with no exemption, but nothing owns where an endpoint gets declared public. Nothing owns whether an endpoint declares the action GATE should enforce, either.

docs/decisions/LB-D4-service-identity-mtls.md

LB-D4 is referenced as decided in &4 and underpins #68, but was never checked in. The rationale for composing LabKit's TLS module rather than generating certificate was only in an epic description.

The record also states the Rust consequence plainly: labkit-rs builds its rustls::ServerConfig with with_no_client_auth() unconditionally, has no client-side TLS type, and never reloads certificates. So a Rust assembly declaring client authentication has to fail validation rather than build and silently ignore it.

Notes for review

Scoped to auth deliberately. The same "which layer owns this" ambiguity exists for resilience policy, observability, and config delivery. Auth is the worst case, so it is a reasonable first instance, but this does not try to be a general boundary document.

Written to describe ownership, not progress. "The chassis composes a LabKit module to verify the URT" stays true whether the work is open or closed; "URT verification is unimplemented" would be stale on merge. Status stays in the tracker and is not restated here.

Docs only. No schema, code, or generator changes.

Reviewer checklist

• Reviewed the changes.
• Change matches the described intent and stays in scope.
• Milestone and labels are applied.
• CI is green.

Related issue

• Supports #87 (URT verification),
• #68 (inbound TLS)
• #71 (outbound transport config)