refactor-safelisted

# Refactor safe A refactor changes structure and preserves behaviour. The danger in an unattended refactor is that behaviour drifts a little at each of forty files and nobody can tell which step did it. The cure is that no step is ever large enough to hide a drift. ## 1 — Establish the net Refactoring code that has no tests is editing code with your eyes closed. Before touching anything, check the coverage of the behaviour you are about to move. Where the net has holes, write **characterisation tests** first: tests that assert what the code currently does, right or wrong. They are not a judgement about correctness — they are the tripwire that tells you the refactor changed something. Behaviour they capture that turns out to be a bug gets fixed in a separate commit, after the refactor, never during. Record the pre-refactor state: the gate output, and for UI, `visual-verify` screenshots of the affected screens. This is your before picture, and without it "nothing changed" is an opinion. ## 2 — Prefer the codemod For a mechanical change across many files — a rename, an import path move, an API signature change — write the transform rather than editing by hand: - The workspace tool's own move and remove generators for project-level moves (`nx g move`, and equivalents), because they update path aliases, project references and the graph — hand-moving a project leaves stale references the compiler finds and the tooling does not - `ts-morph` or `jscodeshift` for TypeScript-aw