Refactor Plan with Safe Ordering

Turn a large refactor into an ordered sequence where every step is shippable on its own.

WHAT EXISTS NOW: {paste code or describe the structure}
WHAT IS WRONG WITH IT: {the actual pain — be concrete: what is slow to change, what breaks often}
WHAT IT SHOULD BECOME: {target}
TEST COVERAGE: {what exists today}

Return:

1. IS THIS WORTH DOING — one honest paragraph. If the pain described is rare or the code is stable and about to be deleted, say to leave it alone. Most refactors are cheaper not to do.

2. SAFETY NET FIRST — the characterisation tests to write BEFORE touching anything, covering the behaviour you must not change. Name them by the behaviour, not by the function.

3. THE SEQUENCE — numbered steps. Each step must:
   - be mergeable on its own
   - leave every test green
   - be revertible without touching the steps before it

4. THE RISKY STEP — there is always one. Name it, say what makes it risky, and how to reduce the blast radius (feature flag, parallel implementation, shadow read).

5. STOPPING POINTS — after which steps the codebase is already better, so the work can be abandoned there without leaving a mess. A refactor that must be finished to be worth anything is a refactor that will be abandoned halfway.