Add connectrpc/authn-go for standardized Connect auth middleware

[haasonsaas]

Context

connectrpc/authn-go (96 stars) provides authentication middleware for Connect-RPC. It extracts auth info from requests and makes it available in the handler context via a typed interface.

Currently, each service calls identity.TokenService_Introspect individually to validate bearer tokens. This means:

• Auth logic is duplicated across services
• Some services may have subtly different token extraction
• Adding a new auth scheme (e.g., mTLS, API keys) requires changing every service

What authn-go provides

authn.NewMiddleware(func(ctx context.Context, req authn.Request) (any, error) {
    // Call identity service to introspect token
    token := req.Header().Get("Authorization")
    claims, err := identityClient.Introspect(ctx, token)
    if err != nil {
        return nil, authn.Errorf("invalid token: %v", err)
    }
    return claims, nil
})

Then in any handler:

claims := authn.GetInfo[*Claims](ctx)
// claims.OrgID, claims.AgentID, claims.Scopes etc.

Integration with service-runtime

This belongs in service-runtime alongside the otelconnect interceptor (PR #132). Services compose interceptors:

mux.Handle(svcconnect.NewGovernanceServiceHandler(&handler{},
    connect.WithInterceptors(
        observability.ConnectOTelInterceptor(),    // tracing
        authmw.ConnectAuthInterceptor(identityClient), // auth
        // future: validate.NewInterceptor()       // validation
    ),
))

Design decision needed

The authmw package already exists in service-runtime. This issue is about evaluating whether connectrpc/authn-go replaces or wraps the existing implementation. Key question: does the existing authmw package already call TokenService_Introspect? If so, this may be a refactor to use authn-go's middleware pattern rather than a net-new addition.

References

• https://github.com/connectrpc/authn-go
• feat: add otelconnect interceptor for per-RPC tracing and metrics #132 — otelconnect interceptor (same pattern)