Add client auth

[davenpi]

What changed?

Implemented complete OAuth 2.1 client authentication system for MCP servers in src/conduit/auth/client/. This provides the foundation for secure MCP server authentication following the MCP authorization specification.

Key components:

• Discovery services - RFC 9728 (Protected Resource Metadata) + RFC 8414 (Authorization Server Metadata)
• Dynamic client registration - RFC 7591 for automatic client setup
• Authorization flow orchestration - Complete OAuth 2.1 code flow with PKCE security
• Token management - Token exchange, refresh, and lifecycle management
• High-level client - OAuth2Client that orchestrates the complete flow
• Authenticated sessions - Token state management with automatic refresh

Why?

The MCP specification requires OAuth 2.1 authentication for protected servers. Without this implementation, conduit-mcp cannot connect to secured MCP servers, limiting its utility in production environments where authentication is essential.

This follows the MCP auth specification's sequence: MCP request → 401 response → discovery → OAuth flow → authenticated requests.

Impact

For developers:

• Enables connection to OAuth-protected MCP servers
• Provides clean abstractions that hide OAuth complexity
• Supports both manual and automated authorization flows

For the codebase:

• Adds ~2000 lines of well-tested OAuth 2.1 implementation
• Maintains clean separation between models, services, and orchestration
• Sets foundation for transport-level auth integration

Standards compliance:

• OAuth 2.1 with PKCE (RFC 7636)
• Resource Indicators (RFC 8707)
• Dynamic Client Registration (RFC 7591)
• MCP authorization specification

Testing

• Comprehensive unit tests for all services (discovery, registration, flow management, token exchange)
• Integration tests for complete OAuth flows
• Error handling tests for network failures and OAuth error responses
• Security tests for PKCE parameter generation and state validation
• Mock-based testing to avoid external OAuth dependencies

All tests use the project's async testing patterns and follow the established testing conventions.

Review notes

• Architecture focus - Clean separation between immutable protocol models and mutable runtime state
• Security implementation - PKCE, state validation, and proper error handling throughout
• String URLs - Deliberately chose str over HttpUrl to avoid Pydantic normalization issues in OAuth flows
• Composable design - Each service can be used independently or as part of the orchestrated flow

The implementation prioritizes correctness and developer experience over brevity - OAuth is complex enough that clarity trumps conciseness.

Checklist

• All new and old tests pass
• Code follows our style guidelines
• Documentation updated if needed
• Breaking changes documented in commit messages

---