test-refactorlisted

# Test refactor pass A pass over a project whose production code has moved and whose tests have not caught up. The order is fixed, the gate between steps is fixed, and the treatment of a red test depends on how much of its class is red. Write tests in the house style: see the `test-style` skill ([../test-style/SKILL.md](../test-style/SKILL.md)) - levels, naming, the given/when/then shape, what may be mocked, what each level has to assert. This document says *what to do and in what order*; that one says *what the result must look like*. ## Unit of work One **module** at a time, in dependency order (a module nobody depends on goes last). Inside a module, a **package is its own step** when it is a meaningful piece of the module - it has its own extension point, its own exceptions, its own value types. A package that is only utilities, containers or DTOs is not a step of its own: it is handled together with the module's root package. Do not touch a module that is not the current step. A defect found in a neighbouring module is written down, not fixed in passing. ## Order within one step ### 1. Read the contract first Before opening a single test: - read `src/main` of the package - the interfaces, then the implementations behind them; - read the javadoc as the contract it claims to be, and note where the code and the javadoc disagree; - find out **how the components are actually used**: grep for the call sites across all modules, not only inside this one. A type's cont