Merge branch 'ef-major-litanies': the Major Litanies, and a kernel bug

Builds the Major Litanies (RG 80, 81, 109(f)) -- an item deferred three
times, each time on a reason that did not survive contact. Two recorded
blockers were false (a kernel signature said to be missing already
carried what was needed; Easter Monday, said to be unmarkable, occurs
exactly 8417 times in 8417 years) and a displacement estimate of ~97.7%
of years measured at 4 years in 46.

8611 days change in four shapes, zero unclassified: the commemoration
appearing on ordinary 25 Aprils, displacing St Mark's own on the four
II-class Sundays RG 111(b) governs, and relocating to the following
Tuesday in the 194 years RG 80's transfer clause fires. No day outside
25/26/27 April differs at all, and observed, rank, colour, season, week
and transferred_in are byte-identical across all 3074246 days.

The entity is a Commemoration_only sanctoral entry, which honours RG 81
structurally rather than by special case: Precedence.resolve partitions
such candidates out of the band contest, so 'nihil fit in Officio' holds
by construction, and being sanctoral-origin it can never claim RG 113's
de-Tempore first place.

And it surfaced a latent kernel bug. Calendar.build_day decided whether
a transferred candidate had settled by testing only whether it became
that day's observed celebration -- correct for every prior use, a losing
feast that wins its unblocked target, and wrong for a Commemoration_only
candidate, which can never be observed by the same status that lets it
transfer. The first fix accepted two settlement channels and the review
found a third: a candidate capped out by admit at its target. That third
case was already visible inside the task's own mutation proof, as an
undiagnosed ninth failure it had set aside.

The fix is a provable no-op in isolation: a3afb19 plus the new
calendar.ml alone, swept over every day of the domain, is byte-identical
to base.

1 files changed, 50 insertions, 10 deletions

diff --git a/lib/rites/rite_ef/precedence_ef.mli b/lib/rites/rite_ef/precedence_ef.mli
index 765b573..419613a 100644
--- a/lib/rites/rite_ef/precedence_ef.mli
+++ b/lib/rites/rite_ef/precedence_ef.mli
@@ -120,17 +120,40 @@ val band : Vocab_ef.season Precedence.context -> Vocab_ef.rank Precedence.candid
     somewhere to be caught other than a silently-wrong RG 33 disposition. *)
 val sunday_marker : string
 
+(** The Major Litanies' own invented slug (RG 80, Caput X "De Litaniis
+    maioribus et minoribus" §A; RG 81; RG 109(f) -- see the .ml's own
+    citation, above [privilege_of], for the full text). Not adopted from
+    lectio, which does not compute the Major Litanies at all (this task's
+    own measurement) -- colitur's own key, data/ef/adjustments.sexp's
+    matching [Add] entry. Exposed for the same reason as
+    {!annunciation_slug} below: a future rename in the data with no
+    matching rename here silently stops {!disposition}, {!admit}'s RG
+    109(f) privilege, and {!transfer_target}'s own RG 80 branch from ever
+    recognising a live candidate again. *)
+val major_litanies_slug : string
+
 (** [disposition ~winner ~loser]: RG 92-95, 33, 21-27, 94 (docs/research/
     rules-register.md §4, "Occurrence", "Vigils" and "Caput IV, 'De
     feriis'"). What becomes of a losing candidate, decided by the LOSER's
     own rank and status (RG 95), except RG 33's vigil omission, which also
     reads the winner:
+    - a loser whose slug is {!major_litanies_slug} (ef-major-litanies task)
+      is [Transfer], NOT [Commemorate], when the WINNER's own slug is
+      Easter Sunday or Easter Monday (RG 80: 25 April's Major Litanies are
+      transferred to the following Tuesday, always Easter+2, when 25 April
+      is itself one of those two days) -- checked first, ahead of the
+      [Commemoration_only] bullet immediately below (of which this would
+      otherwise be a case), because RG 80's own condition overrides RG 81's
+      default "always Commemorate" for these two specific winners only. See
+      the .ml's own citation, and {!transfer_target}'s own RG 80 branch for
+      where the transfer lands;
     - a {!Celebration.status} of [Commemoration_only] is always
-      [Commemorate] (checked first: it can never win -- see
-      {!Precedence.resolve} -- and, by that same status's own definition,
-      already denotes an office with nothing left to translate, so it never
-      transfers either; not itself a further RG citation beyond RG 93's
-      general four-mechanism statement above);
+      [Commemorate] otherwise (checked first among the remaining cases: it
+      can never win -- see {!Precedence.resolve} -- and, by that same
+      status's own definition, already denotes an office with nothing left
+      to translate under RG 95's ordinary rule, so it never transfers
+      either there; not itself a further RG citation beyond RG 93's general
+      four-mechanism statement above);
     - a [Class2] or [Class3] loser whose slug marks it a vigil
       ({!vigil_suffix} OR {!vigil_prefix} -- both conventions this
       codebase's data uses, see {!vigil_prefix}'s own comment) is [Omit]
@@ -243,6 +266,14 @@ val september_ember_prefix : string
     - [observed] a [Class3] or [Class4] day: at most two, by {!band}'s table
       order alone.
 
+    RG 109(f) (ef-major-litanies task): every candidate in [comms] arrives
+    already tagged with its real privilege by {!disposition}, which now
+    includes {!major_litanies_slug} tagged [Privileged] -- this function
+    itself needed no change for it, the same "no new machinery" shape RG
+    109(a)/(c)/(d)/(e) already had: it competes for whichever of the four
+    cases above its host day falls into, exactly like any other privileged
+    candidate.
+
     ADDED, ef-holyname-rg110 task: RG 110 (docs/research/rules-register.md
     §4, Caput XIV) -- "In Officio et Missa S. Petri semper fit
     commemoratio S. Pauli, et vicissim... pro unica habeantur" -- whenever
@@ -339,11 +370,20 @@ val annunciation_slug : string
     *is* {!Colitur_kernel.Rite.t}.transfer_target; see that field's own
     fuller rationale for why the search has to be rite-supplied at all.
 
-    RG 96's own rule: the next following day whose currently-resolved
-    occupant is not I or II class (read off [Vocab_ef.rank], RG 8's dignity
-    -- not {!band}'s finer occurrence-table entry, the same distinction
-    {!admit} draws for RG 111). This general target is computed for EVERY
-    candidate, always, first.
+    RG 80 (ef-major-litanies task): checked FIRST, ahead of everything
+    below -- when [c] is {!major_litanies_slug}, the target is Easter+2
+    directly, with no RG 96 search at all (this candidate is only ever a
+    commemoration at its target, RG 81's own "nihil fit in Officio", which
+    needs no unoccupied day the way a displaced FEAST does; the general
+    RG 96 search below would in fact walk PAST Easter+2, since it is itself
+    I-class). See the .ml's own citation for the full text and the "why not
+    the general search" argument.
+
+    RG 96's own rule, for every OTHER candidate: the next following day
+    whose currently-resolved occupant is not I or II class (read off
+    [Vocab_ef.rank], RG 8's dignity -- not {!band}'s finer occurrence-table
+    entry, the same distinction {!admit} draws for RG 111). This general
+    target is computed for every such candidate, always, first.
 
     RG 96's own named exception (Attamen (a), primary-source-verified --
     see {!annunciation_slug}'s comment for the Latin and the register's own