[Epic]: Platform hygiene and deprecation discipline

### Executive Summary
We want stale configuration to be impossible to ignore, because this repo has no `deny_unknown_fields` anywhere and a dead key sat in prod values unnoticed. This epic exists so config drift is loud rather than silent.

### Strategic Intent
Config that no longer does anything should say so. Silence is how a key survives three releases after the code that read it was deleted.

### Problem Statement
`relying_party.issuer` was removed in #504 and is still set in prod. Nothing warns, because unknown keys are silently dropped workspace-wide. The same silence would hide the next one.

### Desired Outcome
Unknown configuration keys produce a startup warning naming the key; the known dead key is removed from prod; the discovery-URL question is decided and written down.

### Scope (In / Out)
**In:**
- Warn-on-unknown-key at config load
- Removing the dead prod key once the shim and deploy are in place
- Deciding whether prod needs `federation.discovery_url`
- Root-causing the stack-wide container exit 137

**Out:**
- Hard-failing on unknown keys, which would break the retro-compat shim R1 depends on

### Source of truth (links)
- `ai-helm-values/environments/prod/values/lightbridge-app.yaml:983`
- ADR-0025 and its amendment (identity vs location)
- `crates/lightbridge-authz-core/src/config/mod.rs`

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

### Key Assumptions
- Warning is the right severity while a deprecated key is deliberately accepted

### Constraints
- Must not conflict with the R1 retro-compat shim: a deprecated key warns, an unknown key warns, neither aborts

### Risks
- Warning on every unknown key could be noisy against charts that legitimately carry extra keys; scope the check to the parsed config tree

### Success metrics
- A stale key produces exactly one named warning at startup
- Prod values contain no keys the running binary does not read

### 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/

Start by reading crates/lightbridge-authz-core/src/config/mod.rs, the prod values at ai-helm-values/environments/prod/values/lightbridge-app.yaml:983, and ADR-0025 with its amendment. Map the parsed config tree, the retro-compat shim, and the discovery-URL decision before splitting the child work. Done means the named stale key produces exactly one startup warning, unknown keys do not abort, and prod contains no keys the running binary does not read.

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