refactor-verifylisted

# refactor-verify The operator asked for a change that's supposed to preserve behavior — a refactor, a rename, a split, an extract, a dead-code deletion. Your job is to *prove* that behavior was preserved, not just produce a diff that looks right. Behavior-preserving changes are the single biggest source of silent regressions when an LLM touches code. The classic failure is: the AI moves a function, updates the definition, and misses one of several call sites. The tests still pass because coverage was never complete. No one notices until a user hits the broken path. This skill exists to stop that from happening. It covers two change families: 1. **Structural refactors** — move, rename, split, merge, extract, inline. The behavior is supposed to be identical afterward. 2. **Safe deletions** — removing code the operator has confirmed is dead (usually via `fight-repo-rot`). The behavior is supposed to be identical because the code wasn't running. Both families use the same four verification checks. ## The invariant A change is **not done** until all four of these pass: 1. **Symbol-set diff** — every public/exported name that existed before the refactor still exists after it (or was deliberately removed). No silent drops. 2. **AST body diff** — every moved function/class body is structurally equivalent to its original, normalizing whitespace and comments. 3. **Behavioral verification** — typecheck, lint, smoke test (can the code even load?), test suite. All green. 4. **Cal