Add auth server TLS listener and SPIFFE middleware

[jhrozek]

SPIFFE X.509-SVID client authentication needs the client certificate
from a TLS handshake, but the MCP proxy port serves plain HTTP. Give
the embedded authorization server its own TLS listener on port 8443,
so the token endpoint can see client certificates without moving MCP
traffic to HTTPS.

The listener requests client certificates only when spiffe_x509 is
configured, sends the SPIFFE CAs as a hint, and reloads the serving
certificate when its files change, keeping the last good pair.
spiffeauth.Middleware extracts a claimed SPIFFE ID from the presented
peer certificate into the request context; it does not verify the
certificate. Malformed SPIFFE identities receive an OAuth JSON error.
Credential validation remains the responsibility of the client
authentication strategy.

EmbeddedAuthServer gains Start, and the proxy runner starts the
listener on the same host as the MCP port, rejecting a proxy or
diagnostics port that collides with it. Constructors reject configured
TLS listeners without a listener host so unsupported callers fail
explicitly. Graceful shutdown force-closes connections on timeout.

SPIFFE trust configuration remains rejected at startup; this change
does not yet enable SPIFFE client authentication.

Co-authored-by: Mecatl noreply@mecatl.dev

[ChrisJBurns]

Is there a perhaps a breaking change here due to the func signature changing? Nothing in codebase but any out of tree callers?

[jhrozek]

Good question. The change is source-compatible for anyone calling the constructors directly, because the new opts parameter is variadic. It would only break code that stores NewEmbeddedAuthServer or NewEmbeddedAuthServerWithStorage as a func value, or implements an interface or mock against the old signature.

I checked all in-repo callers (pkg/runner, pkg/vmcp/cli, the integration helpers) and the downstream consumers I know of. All of them call the constructors directly, so none breaks.

One behavior change to be aware of: the constructors now reject a configured TLS listener when no WithListenerHost is passed. That only applies to callers that set the new TLS listener config, which doesn't exist yet in any released version, so existing callers are unaffected.