feat: add agent audience scope to platform clients during registration

[mrsabath]

Summary

• Client-registration sidecar now creates an audience scope for the agent and adds it to platform clients (e.g., the kagenti UI client)
• This eliminates the need for manual Keycloak configuration to make AuthBridge-protected agents reachable from the UI
• New optional env vars: PLATFORM_CLIENT_IDS (default: kagenti), KEYCLOAK_AUDIENCE_SCOPE_ENABLED (default: true)

Problem

When an agent with AuthBridge is deployed, the client-registration sidecar registers it as a Keycloak client, but existing clients (like the UI) don't get the agent's audience scope. This means the UI can't chat with AuthBridge-protected agents — the token's audience doesn't include the agent's SPIFFE ID.

Solution

After registering the client, the sidecar now:

1. Creates an audience scope (agent-{namespace}-{name}-aud) with an audience mapper
2. Adds it as a realm default (for future clients)
3. Explicitly adds it to platform clients specified by PLATFORM_CLIENT_IDS

All operations are idempotent. The feature is enabled by default and can be disabled with KEYCLOAK_AUDIENCE_SCOPE_ENABLED=false.

Files changed

• AuthBridge/client-registration/client_registration.py — Core audience scope logic
• kagenti-webhook/internal/webhook/injector/container_builder.go — Pass PLATFORM_CLIENT_IDS env var to sidecar
• kagenti-webhook/internal/webhook/injector/container_builder_test.go — Test for new env var
• AuthBridge/demos/single-target/k8s/configmaps-webhook.yaml — Document new config option

Test plan

• Go unit test passes (TestBuildClientRegistrationContainer_HasPlatformClientIDsEnv)
• All existing injector tests pass (30/30)
• Tested on Kind cluster — scope created, added to kagenti UI client
• Verified idempotency — multiple pod restarts produce no errors
• E2E: UI can chat with AuthBridge-protected agent after deploy (no manual Keycloak step)

Closes #169

🤖 Generated with Claude Code