POC : Token Exchange for Partners not using bc registries realm for authentication

Tasks - bcregistry realm (RH-SSO):
1. Register partner realm as an external OIDC IdP
- Alias: -realm
- Discovery endpoint: /.well-known/openid-configuration
- Client ID / secret: as provided by partner
- Trust email: OFF (users may not have email; do not rely on email for identity)

2. Configure the first-login flow for interactive linking (no email matching, no auto-create)
- Duplicate the default first broker login flow → name it first-broker-login-partner
- Disable Create User If Unique (no auto-provisioning of BCROS users)
- In Handle Existing Account subflow:
- Keep Confirm Link Existing Account as REQUIRED
- Keep Verify Existing Account by Re-authentication as REQUIRED - this shows the BCROS sign-in page so the user proves ownership using their existing auth method (BCSC / BCeID / IDIR / etc.), no email needed
- Bind this flow to the partner realm IdP (First Login Flow field on the IdP entry)

3. Create partner-service confidential client
- Client authentication: ON
- Standard flow: ON (needed for interactive linking redirect)
- Service accounts: ON
- Standard Token Exchange: ON (client attribute standard.token.exchange.enabled=true)
- Valid Redirect URIs: partner backend callback URL (e.g. https:///link/callback)
- Full Scope Allowed: OFF - restrict scopes to only what partner needs

4. Grant token-exchange permissions
- partner-service client → Permissions → token-exchange → enable → client policy allowing itself
- Partner realm IdP → Permissions → token-exchange → enable → client policy allowing partner-service

5. Assign the client scopes / roles the partner should be able to act on
- Only what pay-api needs for partner-driven payments
- Explicitly NOT staff / admin scopes

Tasks - Partner realm (coordinate with partner):

1. Add bcregistry broker endpoint to their client's Valid Redirect URIs:
https://test.loginproxy.gov.bc.ca/auth/realms/bcregistry/broker//endpoint

2. Confirm their realm's OIDC discovery URL is reachable from RH-SSO

Testing / Verification:
- Partner backend obtains a partner realm token for a test user
- First token exchange fails; partner backend redirects the browser through the linking flow
- User is prompted with the BCROS sign-in page and authenticates using their normal BCROS credentials (no email required)
- Federated identity link visible on BCROS user (Identity Provider Links tab)
- Second and subsequent token exchanges succeed silently
- BCROS API accepts the token; pay-api uses Account-Id header for account context
- Test with a BCROS user that has no email - flow still works