consolidation-scanlisted

# Consolidation Scan Survey the codebase for **emerging, unnamed** duplicate or near-duplicate logic — the same responsibility implemented independently in two or more places — weight candidates by how actively their files are being edited, and track them across multiple weekly runs in a local ledger before proposing anything. This skill makes **no code changes** — it reads and reports only. **Scope note — how this differs from `entropy-scan`:** `entropy-scan` is stateless and deterministic — it checks a fixed set of *named* rules from `references/principles.md`, each with an explicit `**Detection:**` instruction, and every run stands alone. `consolidation-scan` is the opposite shape: there is no named rule to check against. It relies on judgment — an LLM reading and comparing the *purpose and structure* of code across files and services — to notice duplication that a deterministic checker can't name in advance. Because a single pass of judgment-driven comparison is noisy and prone to one-off false positives, this skill never proposes anything from a single run: it persists what it finds in `state/consolidation-ledger.json` and only promotes a candidate once it has recurred, with a stable shape, across multiple runs (Rule of Three — see Step 6-7). Static clone-detection tools (jscpd, SonarQube CPD) are explicitly not used here — they only catch textual/token clones; this skill's job is to catch *semantic* duplication that shares no lines at all (e.g. three independently-wri