Add audit logging to authserver

Context

The authserver is the most security-sensitive component in ToolHive (token issuance, client registration, upstream IDP interaction) yet has zero audit logging. The rest of the codebase has a mature NIST SP 800-53 compliant audit system in pkg/audit/ with structured event types, subjects, targets, and outcomes.

Scope

Define auth event types

New EventType constants in pkg/audit/ (new file authserver_events.go, following mcp_events.go pattern). Failures are NOT separate event types — they are captured via the existing Outcome field (success, failure, error, denied) on each event.

Plus supporting subject keys (oauth_client_id, upstream_issuer, upstream_subject), target keys (session_id, scope, resource, grant_type, revocation_reason), and component constant (toolhive-authserver).

NIST SP 800-53 AU-2 coverage

Future events (oauth_token_introspected, oauth_mtls_auth_attempted, oauth_client_updated/deleted) should be added when their corresponding features land.

Create AuthServerAuditor and wire into handlers

Follow the WorkflowAuditor pattern (pkg/audit/workflow_auditor.go) — a direct auditor that handlers call, rather than generic HTTP middleware. This is preferred because auth operations have rich semantic context (client_id, grant_type, upstream_provider) that HTTP middleware can't capture, and different endpoints need very different audit data.

Wire into each handler:

• AuthorizeHandler: oauth_authorize_request with subjects={client_id}, target={redirect_uri, scope, resource}
• CallbackHandler success: oauth_upstream_auth_complete + oauth_auth_code_issued + optionally oauth_user_created
• CallbackHandler failure: oauth_upstream_auth_complete with outcome=failure/error
• TokenHandler authorization_code: oauth_token_issued with subjects={client_id, user_id, session_id}, target={grant_type, scope}
• TokenHandler refresh_token: oauth_token_refreshed with subjects={client_id, user_id}, target={grant_type}
• TokenHandler failure: relevant event type with outcome=failure
• RegisterClientHandler: oauth_client_registered with subjects={client_id, client_name}
• Upstream token refresh (when implemented): oauth_upstream_token_refreshed with target={upstream_issuer, session_id}
• Session revocation (when implemented): oauth_session_revoked with target={session_id, revocation_reason}

Acceptance criteria

• Auth event type constants defined in pkg/audit/authserver_events.go
• AuthServerAuditor created following WorkflowAuditor pattern
• Auditor injected into Handler via constructor
• Audit events emitted for all handler success and failure paths
• Sensitive data (tokens, PKCE verifiers, authorization codes) NEVER included in audit events
• Source information (client IP, user agent) included in events
• Configuration follows pkg/audit.Config patterns (enable/disable, event type filtering)
• Unit tests verify correct event types, subjects, and outcomes per handler path

Dependencies

• Depends on #3918 (HTTP middleware — request IDs needed for audit event correlation)

Start by reading pkg/audit/mcp_events.go and pkg/audit/workflow_auditor.go, then trace AuthorizeHandler, CallbackHandler, TokenHandler, and RegisterClientHandler. Define the event constants and auditor, inject it into Handler, and add tests for success and failure paths; done means all listed events include the required context without sensitive data and follow pkg/audit.Config filtering.