issue-root-resolutionlisted

# Issue Root Resolution A cluster is resolved when the mechanism that permits it is removed or guarded at the correct boundary, each affected report has executable evidence, and the implementation remains faithful to Rembric's specifications and invariants. Do not turn a cluster into a collection of symptom patches. ## 1. Establish the current mechanism Work from current `origin/main`, not an issue's historical description. 1. Read full issue bodies, comments, linked PRs, and relevant OpenSpec specs. 2. Reproduce every candidate root through a real caller boundary; include a passing control in the same run. 3. Make a read-only mechanism map before editing. Every claim gets a `file:line` anchor and explains what happens today, not what the issue says should happen. 4. Record report date and the commit/release being tested. A pre-fix report is not evidence that the current build remains broken. If the map contradicts the report, say so. The symptom may be valid while the proposed mechanism is wrong; strengthen the repro until it distinguishes them. ## 2. Shape the smallest root fix Rank alternatives in this order: 1. remove the mechanism, making the whole class impossible; 2. add a static/invariant guard that makes reintroduction fail; 3. apply a local predicate fix behind a failing real-surface reproduction; 4. only when evidence rules out the above, add a new state, flag, command, compatibility path, or other lasting surface. For every option that adds