precedence(ef): fix round 1 (F1) -- band's -14 sentinel inverted the table

entry_14_movable_band = -14 was justified only by "cannot collide
with a real table position (1..28) or unclassified" -- a collision
argument, not an ordering one. band's own value is compared by plain
<, so a negative number beats every I-class entry (1-13), not merely
the fixed Baptism it was built to beat. Not live against the shipped
universal sanctoral data (no I-class universal feast falls 7-13
January, which is why the original 1583-9999 sweep showed only the
intended shape), but entries 12/13 admit PROPER and INDULT I-class
feasts too, and those arrive via adjustments.sexp-style overlays --
this architecture's own advertised extension path. A diocesan
patronal feast landing in Holy Family's window would have made the
inversion live immediately: the I-class feast displaced and
transferred to the next day, reproduced and confirmed before this
fix, reverted after.

Fixed by rescaling every band branch to the real RG 91 entry number
times ten (unclassified untouched at max_int) instead of the bare
1..28, reserving genuine headroom immediately before each entry for
a movable sub-rank -- not an arbitrary rescale: RG 91's own text
records a "primum mobilia, deinde fixa" split at three rows, not
only entry 14 (entry 12's own ninth sub-item, entry 14, and entry
20), so this leaves room for the other two without a second rescale
if either ever gets a live witness. entry_14_movable_band now
derives from entry_14_fixed_band - 1, tied together so they cannot
drift apart.

Added a synthetic I-class end-to-end test reproducing the exact
counter-example that found this: a universal I-class candidate
inside Holy Family's own 7-13 January window is now observed and
does not transfer, with Holy Family itself falling to RG109(a)'s
ordinary privileged-Sunday-commemoration path, the same treatment
any genuine feast outranking an ordinary Sunday gets.

1 files changed, 28 insertions, 13 deletions

diff --git a/lib/rites/rite_ef/precedence_ef.mli b/lib/rites/rite_ef/precedence_ef.mli
index 86a0ead..239a254 100644
--- a/lib/rites/rite_ef/precedence_ef.mli
+++ b/lib/rites/rite_ef/precedence_ef.mli
@@ -62,25 +62,40 @@ val ember_prefixes : string list
     new rule, not a silently wrong one. *)
 val unclassified : int
 
+(** {!band}'s value for RG 91 entry 14's FIXED half (a sanctoral, i.e.
+    fixed-date, Class2 feast of the Lord) -- see {!entry_14_movable_band}'s
+    own comment for why entry 14 needs two distinct values at all. *)
+val entry_14_fixed_band : int
+
 (** RG 91 entry 14's own text (§4): "Festa Domini II classis, primum
     mobilia, deinde fixa" -- feasts of the Lord, II class, MOVABLE first,
     then fixed. {!band}'s value for the movable half (Holy Family, RG
-    17(b)) -- strictly better than the fixed half's own literal [14],
-    negative so it can never collide with a real table position or
-    {!unclassified}. See precedence_ef.ml's own comment for the full
-    citation and why the two halves must not literally tie. *)
+    17(b)) -- [entry_14_fixed_band - 1], strictly better than the fixed
+    half without colliding with entry 13 or any other real table position.
+    CORRECTED, fix round 1 (coordinator finding 1): this used to be a
+    negative sentinel, justified only by "cannot collide with a real table
+    position" -- a COLLISION argument, not an ORDERING one; since {!band}
+    values are compared by plain [<], a negative value beats every I-class
+    entry (1-13) as well as the fixed half, not merely the fixed half it
+    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. *)
 val entry_14_movable_band : int
 
 (** [band ctx c]: RG 91's Table of Precedence. Returns the table's own entry
-    number -- I class 1-13, II class 14-21, III class 22-26, IV class 27-28;
-    lower wins (see {!Precedence.rules.band}) -- EXCEPT where the table's own
-    text states an exception: entry 8 (All Souls) reads "yields to an
-    occurring Sunday", so on a Sunday this returns a value that
-    loses to entry 15 rather than the literal integer 8 (see the comment on
-    entry 8 in precedence_ef.ml for the exact value and why). ALSO
-    {!unclassified} for any [Cel.Commemoration_only] candidate, checked
-    first, ahead of every rank-keyed branch -- CORRECTED, Task B fix round
-    1 (coordinator finding 1): RG 91's own table enumerates only "dies
+    number TIMES TEN -- I class 10-130, II class 140-210, III class 220-260,
+    IV class 270-280; lower wins (see {!Precedence.rules.band}) -- EXCEPT
+    where the table's own text states an exception: entry 8 (All Souls)
+    reads "yields to an occurring Sunday", so on a Sunday this returns a
+    value that loses to entry 15 (150) rather than 80 (see the comment on
+    entry 8 in precedence_ef.ml for the exact value and why); entry 14
+    (Feasts of the Lord, II class) splits into {!entry_14_movable_band} and
+    {!entry_14_fixed_band} per the table's own "primum mobilia, deinde
+    fixa". ALSO {!unclassified} for any [Cel.Commemoration_only] candidate,
+    checked first, ahead of every rank-keyed branch -- CORRECTED, Task B fix
+    round 1 (coordinator finding 1): RG 91's own table enumerates only "dies
     liturgici" (entry 24's own text, "Festa III classis..." -- FEASTS), so
     a celebration reduced to a bare commemoration was never a row in the
     table to begin with, confirmed by the calendarium's own notation (a