docs: two retracted claims that outlived their retraction

Both are the defect class this fix round existed to close, which is why
they are worth recording rather than quietly overwriting.

CLAUDE.md still carried F1's retracted design rationale -- describing
entry_14_movable_band as "negative so it can never collide with a real
table position" -- and F2's retracted transcription-defect attribution,
verbatim, in the one tracked file the project's own workflow tells a
fresh session to read first. The fix round struck both everywhere else
and missed this file. A session following it as instructed could have
re-derived the negative sentinel for entry 20's or entry 23's movable
half and re-introduced the inversion in a new branch.

precedence_ef.ml's replacement justification for the x10 rescale then
introduced a fresh misstatement of the same primary text it was
correcting: it attributed "primum mobilia, deinde fixa" to "entry 12's
own ninth sub-item" and counted three such rows. Both photographic
scans, and the register's own section 4 table, put that clause at entry
13; entry 12 has eight sub-items and no such clause. The split occurs at
five rows -- 13, 14, 20, 23's third sub-item, and 24. Entry 24 is the
most-evaluated band in the whole domain and is unsplit in the code,
which is precisely the sub-rank the new headroom exists to hold.

Corrected in the .mli and the register too. No behaviour change; 290
tests green.

2 files changed, 19 insertions, 7 deletions

diff --git a/lib/rites/rite_ef/precedence_ef.ml b/lib/rites/rite_ef/precedence_ef.ml
index 635a69f..374e9a4 100644
--- a/lib/rites/rite_ef/precedence_ef.ml
+++ b/lib/rites/rite_ef/precedence_ef.ml
@@ -74,11 +74,20 @@ let unclassified = max_int
    TIMES TEN (entry 1 -> 10, entry 28 -> 280, {!unclassified} untouched at
    [max_int]) instead of the bare 1..28 -- not an arbitrary rescale, a
    deliberate one: RG 91's own text records a "primum mobilia, deinde
-   fixa" (movable-then-fixed) split at THREE rows, not only this one --
-   entry 12's own ninth sub-item ("Festa indulta I classis, primum
-   mobilia, deinde fixa"), entry 14 (this one), and entry 20 ("indult
-   II-class feasts (movable then fixed)", register §4's own summary) --
-   and only entry 14 has a live witness in this codebase's data today. The
+   fixa" (movable-then-fixed) split at FIVE rows, not only this one --
+   entry 13 ("Festa indulta I classis, primum mobilia, deinde fixa", its
+   own numbered row on both scans), entry 14 (this one), entry 20, entry
+   23's third sub-item ("deinde festa indulta, primum mobilia, deinde
+   fixa"), and entry 24 ("Festa III classis, in calendario Ecclesiae
+   universae inscripta, primum mobilia, deinde fixa") -- and only entry 14
+   has a live witness in this codebase's data today. NOTE, corrected by the
+   fix-round re-review: this comment previously said THREE rows and
+   attributed the first to "entry 12's own ninth sub-item". Both scans, and
+   the register's own §4 table, put that clause at entry 13; entry 12 has
+   eight sub-items and no such clause. Entry 24's split is the notable
+   omission -- it is the most-evaluated band in the whole domain and is
+   unsplit here, which is exactly the kind of sub-rank this headroom exists
+   for. The
    ×10 scale reserves nine integers of genuine headroom immediately BEFORE
    each real entry's own value for exactly this kind of sub-rank, without
    requiring a second rescale if entry 12's or entry 20's own movable half
diff --git a/lib/rites/rite_ef/precedence_ef.mli b/lib/rites/rite_ef/precedence_ef.mli
index 7d0bc98..6a96c4e 100644
--- a/lib/rites/rite_ef/precedence_ef.mli
+++ b/lib/rites/rite_ef/precedence_ef.mli
@@ -80,8 +80,11 @@ val entry_14_fixed_band : int
     was built to beat. {!band}'s own entries now use the real RG 91 number
     TIMES TEN throughout, reserving genuine headroom before every entry --
     see precedence_ef.ml's own comment for the full citation, the counter-
-    example that found this, and why entries 12 and 20 may need the same
-    treatment if their own "movable then fixed" halves ever get a witness. *)
+    example that found this, and why entries 13, 20, 23 and 24 may need the
+    same treatment if their own "movable then fixed" halves ever get a
+    witness. (Corrected: this previously said "entries 12 and 20". RG 91
+    puts that clause at entry 13, not 12, and the split occurs at five rows
+    in all -- 13, 14, 20, 23's third sub-item and 24.) *)
 val entry_14_movable_band : int
 
 (** [band ctx c]: RG 91's Table of Precedence. Returns the table's own entry