[Epic]: Verify and consolidate the live 5.1 IdP release

### Executive Summary
We want the already-live 5.1 IdP release confirmed, verified, and cleanly consolidated, because prod has been running #504's binary since 2026-08-26 without anyone verifying it end to end or tidying the configuration it left behind. This epic exists to close the gap between "deployed" and "known good".

> **This epic was rewritten on 2026-08-26.** It originally assumed prod ran a pre-5.1 image and planned a retro-compatibility shim plus a coordinated rollout. That premise was wrong - the image pin is automated and prod was already on `4f9e17d`. #511 and #512 are closed as moot; what remains is verification and cleanup.

### Strategic Intent
Deployed is not the same as verified. An automated pin moved prod onto a release carrying a breaking config change, and it worked - but nobody proved it, and the reason it worked (unknown config keys are silently ignored) is an accident rather than a decision.

### Problem Statement
Prod runs `sha-4f9e17d63d543c57318b8b12835578fc8351fcec` = commit `4f9e17d` = #504. Discovery and every advertised route are confirmed serving. Three things are still open:

1. No device-code login has been exercised against prod.
2. There is no written rollback procedure, and rollback currently works only by accident - a pre-#504 binary REQUIRES `oauth2.relying_party.issuer`, which survives in the prod values file only because nobody has removed it yet.
3. The semver release (5.1.0) has not been cut, so there is no changelog recording the breaking change.

### Desired Outcome
A verified prod deployment: a real login exercised end to end, a written rollback procedure, and a tagged release whose changelog names the config change.

### Scope (In / Out)
**In:**
- Device-code login verified against prod
- A written, tested rollback procedure
- Cutting 5.1.0 for the changelog and chart version
- Documenting the local `compose.it.yaml` published-ports trap

**Out:**
- A retro-compatibility shim (#511, closed - the transition already completed)
- A coordinated rollout (#512, closed - already satisfied)
- Removing the dead prod config key - tracked under #509, and gated on the rollback decision

### Source of truth (links)
- https://github.com/ADORSYS-GIS/lightbridge-authz/pull/502
- https://github.com/ADORSYS-GIS/lightbridge-authz/pull/504
- Prod discovery verified 2026-08-26: `https://auth.ai.camer.digital/.well-known/openid-configuration`
- `ai-helm-values` pin commit `32af3d4`

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

### Key Assumptions
- The automated image pin will keep tracking `main`, so future releases reach prod the same way
- ArgoCD auto-syncs on commit to `main` in the values repo, as that file's own header states

### Constraints
- Rollback to a pre-#504 image depends on `relying_party.issuer` remaining in the prod values file. Removing it is a one-way door.
- Every new or changed file under `src/` stays at or below 200 LoC; single-responsibility modules (SOLID); no copy-pasted logic (DRY).

### Risks
- **The automated pin means `main` reaches prod without a human release decision.** Combined with the known property that signed images are pushed before the test verdict (#499), a red build can be pinned to prod. This deserves its own follow-up.
- Rollback has never been exercised. A procedure that has not been run is a hypothesis.

### Success metrics
- A device-code login completes against prod
- A rollback procedure exists and has been walked through
- 5.1.0 tagged, changelog naming the removed config key

### Child User Stories
Tracked as sub-issues.

### Human accountable owner
@stephane-segning

### AI Usage Declaration
Epic decomposition was AI-assisted. The original version encoded a wrong assumption about production state; it was corrected after verifying the actual image pin and live discovery document. 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/

Start with the production discovery document, the ai-helm-values pin at commit 32af3d4, and the linked #502 and #504 changes. Review the child issues, #509, and compose.it.yaml before deciding the verification and rollback sequence. Done means a production device-code login is completed, rollback has been walked through and documented, 5.1.0 is tagged with the config change in the changelog, and the published-ports trap is documented.

由索引模型根据 Issue 内容生成。