[Epic]: Code quality ratchet - 200 LoC per file, SOLID, DRY

### Executive Summary
We want file size and cohesion to stop degrading, because 32 of 101 `src/*.rs` files already exceed 200 LoC by a combined 24,010 lines, with the worst at 4,068. This epic exists to stop the bleeding first and fund the burn-down second.

### Strategic Intent
Make the 200-LoC rule real rather than aspirational. A rule that is violated by a third of the tree on day one is not a rule, it is a wish.

### Problem Statement
Measured on `main` at 2026-08-26: 32/101 `src` files over 200 LoC, 24,010 excess lines. Big-bang compliance is roughly 40+ dev-days of pure refactor - more than both releases combined - and every line of it is churn on an authentication boundary. Doing it all at once would be reckless; doing none of it lets the trend continue.

### Desired Outcome
New and changed code cannot exceed 200 LoC (enforced in CI), the existing debt is published as a tracked baseline, and the four worst offenders are split.

### Scope (In / Out)
**In:**
- CI gate on new/changed `src` files (a ratchet, not a big-bang)
- Published LoC baseline and burn-down plan
- SOLID/DRY reviewer checklist in the PR template
- Splitting the top offenders, highest first

**Out:**
- Test files: a 200-line cap on a 6,052-line integration suite is a different conversation, tracked separately
- Any behavioural change; these splits are strictly mechanical

### Source of truth (links)
- Measured on `main` 2026-08-26 via `find crates app -name '*.rs' -path '*/src/*' | xargs wc -l`
- Repository code-style rules in `AGENTS.md`

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

### Key Assumptions
- 200 LoC is measured on `src/` only
- Splits are behaviour-preserving and provable by the existing suite

### Constraints
- Refactors must not change behaviour on an authentication boundary
- The existing suite must stay green at every commit

### Risks
- A mechanical split that silently changes module visibility or trait-object coercion (`E0277` unsizing has bitten this tree before)
- A ratchet gate that fires on unrelated PRs and gets disabled out of frustration

### Success metrics
- 0 new `src` files over 200 LoC after the gate lands
- Files over 200 LoC reduced from 32 toward 28 by 2026-09-04
- Excess-line count published and trending down

### 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 with AGENTS.md and the repository's existing CI and PR-template configuration. Reproduce the baseline with the referenced find crates app -name '*.rs' -path '*/src/*' | xargs wc -l command, then review the four largest src offenders and the existing suite. Done means the ratchet, published baseline, checklist, and behavior-preserving splits are delivered without changing test behavior.

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