[Epic]: One trust root for the platform

### Executive Summary
We want a single sign-in to reach every lightbridge service, because today `authz-idp` tokens are refused by `authz-api` and the console must authenticate against Keycloak directly. This epic exists to decide whether the platform has one token-issuing authority or two.

### Strategic Intent
Resolve a genuine architectural fork rather than letting it settle by accident.

### Problem Statement
`lightbridge-authz-bearer` validates against a single `oauth2.jwks_url` and pins `iss` to `oauth2.federation.issuer`. `authz-idp` mints with its own DB-held signing keys. Two trust roots means a console login through `authz-idp` gets 401 from every management RPC.

### Desired Outcome
A written ADR settling the question, and - if accepted - multi-issuer validation so one login reaches both planes.

### Scope (In / Out)
**In:**
- The ADR and its trade-off analysis
- Multi-issuer JWKS validation, if the ADR accepts it

**Out:**
- Any implementation before the ADR is accepted

### Source of truth (links)
- `crates/lightbridge-authz-bearer/src/lib.rs:38`
- ADR-0011, ADR-0023, ADR-0025

### Stakeholders
Platform team (4 advanced + 2 senior engineers), Scrum Master, prod operators.

### Key Assumptions
- This is deliberately unscheduled: R3 or later, informed by what R2 teaches

### Constraints
- Accepting a second signing root widens the authentication boundary and deserves the full fail-closed review, not a quick config addition

### Risks
- Multi-issuer validation done carelessly is an algorithm/issuer-confusion vulnerability. The unavailable branch must never become the permissive branch

### Success metrics
- ADR accepted or rejected with reasons recorded
- If accepted: the console performs one login and reaches both planes

### Child User Stories
Tracked as sub-issues of this epic.

### Human accountable owner
@stephane-segning

### AI Usage Declaration
Epic decomposition and estimation were AI-assisted.
Structure and estimates drafted with AI from a verified repository audit (file
line counts, config keys, and dependency state were read from the actual tree,
not assumed). A human owns intent, scope, and the release commitment.

### Human verification completed
- [ ] I can explain this work without referring to the AI-generated text
- [ ] Acceptance criteria are testable
- [ ] Source of truth is a real link, not boilerplate

Governance: https://adorsys-gis.github.io/ai-governance/