feat(api): re-derive verdicts on a policy edit

PUT /api/policies/{id} changed the rule every title under every root
pointing at the policy is judged by, and re-derived nothing, so §9.3's
deck and the daemon's grab gate kept reading verdicts computed under
rules that no longer existed.

Drives #241's walker from a policy id: root by root through
reclassify::root, so the skip rules and the leave-unchanged-rows-alone
rule stay in one place. A rename touches no rule and walks nothing.

Inline still holds at this width. Measured on a release build over 2000
titles and 10 000 stored releases across two roots sharing one policy:
0.36 s when no verdict moves, 2.7 s when all 10 000 do. DESIGN.md §5.1
now names four actions and carries those numbers.

just ci passed through the gate.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

DESIGN.md

@@ -201,14 +201,23 @@ both directions — `only_4k` tightens, `allow_english_audio` loosens.
 
 **Stored verdicts follow the effective policy.** A release's verdict is
 stamped by the search that found it, and both §9.3's deck and the daemon's
-manual-grab gate read that stored column. So the three operator actions that
+manual-grab gate read that stored column. So the four operator actions that
 change a title's effective policy — editing its overrides, moving it to a
-root with a different policy, and pointing a root at a different policy —
-re-derive the stored verdicts of everything they touch, inline in the same
-request. The operator is never left reading a verdict computed under a
-policy that no longer applies. Inline is affordable even root-wide:
-re-evaluation is pure and in-memory, and a row whose verdict does not move
-is not rewritten, so a library-sized repoint costs reads, not writes.
+root with a different policy, pointing a root at a different policy, and
+editing the contents of a policy some root points at — re-derive the stored
+verdicts of everything they touch, inline in the same request. The operator
+is never left reading a verdict computed under a policy that no longer
+applies.
+
+The fourth is the widest: a repoint moves one library, a policy edit moves
+every library sharing the policy. Inline still holds there. Re-evaluation is
+pure and in-memory, a row whose verdict does not move is not rewritten, and
+the ceiling is the whole database rather than something that grows with the
+number of roots — roots partition titles, and a title has exactly one root.
+Measured over 2000 titles and 10 000 stored releases split across two roots
+sharing one policy: 0.36 s when the edit moves no verdict, 2.7 s in the
+pathological case where it moves all 10 000. A rename changes no rule and
+re-derives nothing.
 
 ### 5.2 Language