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, 88 insertions, 0 deletions

diff --git a/data/ef/adjustments.sexp b/data/ef/adjustments.sexp
index 740180c..a5e7c6f 100644
--- a/data/ef/adjustments.sexp
+++ b/data/ef/adjustments.sexp
@@ -165,6 +165,87 @@
 ; (Commemoration_only entries are never the OBSERVED celebration, so this
 ; entry's OWN colour is never printed by the current pipeline, the same
 ; note `Edit eusebius-confessor` above makes for its own colour field).
+;
+; `Add major-litanies` -- NEW (ef-major-litanies task). RG 80 (Caput X, "De
+; Litaniis maioribus et minoribus", §A "De Litaniis maioribus"; all three
+; primary documents -- both photographic scans AND the electronic
+; transcription -- word for word, no divergence to adjudicate): "80.
+; Litaniae maiores assignatae sunt diei 25 aprilis; si vero eo die
+; occurrit dominica Paschatis vel feria II post Pascha, transferuntur in
+; sequentem feriam III." RG 81, same division: "81. De Litaniis maioribus
+; nihil fit in Officio, sed tantum in Missa. Earum autem commemoratio non
+; est habenda commemoratio 'de Tempore'." RG 109(f) (Caput XVI, "De
+; Commemorationibus"): "f) de Litaniis maioribus, in Missa" -- a
+; privileged commemoration. The calendarium's own April table (all three
+; documents, e.g. the transcription: "iv c vii 25 Litania Maior. - S.
+; MARCI EVANGELISTAE, II classis.") prints "Litania Maior" as part of 25
+; April's own descriptive line, alongside St Mark, not as a second,
+; separately class-numbered row -- corroborating RG 81's "nihil fit in
+; Officio" the same way Maurice's own "Commemoratio ... " line (no class
+; number) corroborates a demoted feast elsewhere in this project (see
+; precedence_ef.ml's [band], top-of-function guard).
+;
+; MODELLING DECISION: `Commemoration_only`, `Fixed(4, 25)`, the same shape
+; as `commemoration-of-st-peter` above -- because RG 81 denies the
+; Litanies any Office standing at all ("nihil fit in Officio"), so they
+; can never be the OBSERVED day (RG 91's table enumerates "dies
+; liturgici", Office days, and this is explicitly none), only ever a Mass
+; commemoration. `Precedence_ef.disposition`/`.privilege_of` wire RG
+; 109(f)'s privilege and RG 80's own transfer condition (both cited in
+; full at `Precedence_ef.major_litanies_slug` and its two call sites); see
+; that module for the reasoning and precedence_ef.ml's own comments for
+; why the transfer reuses the existing RG 96 placement machinery
+; ({!Colitur_kernel.Precedence.Transfer}) rather than new machinery.
+;
+; `rank Class4`: RG 91's Table of Precedence has NO row for the Major
+; Litanies at all (RG 81 denies them Office standing; the calendarium's
+; own printed line above confirms it), so there is no class this data
+; field could faithfully report -- the same situation `band`'s own
+; top-of-function guard already documents for every `Commemoration_only`
+; entry ("never had a row in the table for that occasion to begin with").
+; `Class4` is chosen as the lowest/inertest value available, deliberately
+; NOT `Class1` (which would make `Precedence_ef.privilege_of`'s branch (b),
+; "of a I-class day", grant this entry Privileged status for the WRONG
+; cited reason, silently making the (f) branch this task wires dead code
+; again). `band` ignores rank entirely for any `Commemoration_only`
+; candidate (checked first, unconditionally); `admit`'s only rank-keyed
+; test for an ordinary (non-privileged) II-class-Sunday commemoration
+; never applies here either, since this entry is always Privileged. No
+; live behavioural consequence either way -- recorded as a deliberate,
+; honestly-flagged placeholder, not a citation.
+;
+; `colour Violet`: NOT independently scan-verified for this specific
+; entry (out of this task's scope -- Mass propers are Plan 4, `citations`
+; stays `()`). Matches, by internal consistency, the colour this same
+; codebase already assigns the sibling Minor Litanies/Rogation days
+; (`rite_ef/temporal_ef.ml`'s own Rogation branch: `~colour:Colour.Violet`
+; for RG 87's Monday/Tuesday before Ascension) -- both are "Litaniae",
+; major and minor, sharing the same penitential/processional character;
+; RG 80/81/109(f) themselves say nothing about colour. Inert today
+; regardless (`Commemoration_only` entries are never OBSERVED, so this
+; field is never printed by the current pipeline -- the same note `Edit
+; eusebius-confessor` above makes for its own colour field).
+;
+; `subject Saint`: no clean fit among {Lord, Bvm, Saint, Temporal} -- the
+; Litanies are tied to no particular Divine Person or to the BVM (RG 80/81
+; name no one), and are far from an ordinary saint's feast either, but
+; `Subject.Temporal` is reserved for the temporal cycle's OWN office
+; (`subject.mli`), which this Fixed, sanctoral-origin entry structurally
+; is not. `Saint` is the same "no special exclusion applies" default this
+; codebase's own other `Commemoration_only` sanctoral entries already use
+; (RG 110's own Peter/Paul companion entries, `commemoration-of-st-peter`
+; immediately below) -- its only live behavioural consequence anywhere in
+; this codebase, RG 112(a)/(d)'s Lord/BVM mutual-exclusion rules, is one
+; this entry should NOT trigger either way, so `Saint` is safe as well as
+; consistent.
+;
+; `names`: English ("The Major Litanies") is a plain translation of RG
+; 80's own "Litaniae maiores", not independently primary-sourced (no
+; English title exists in any of the three documents, all Latin). Polish
+; ("Litanie Większe") likewise a plain vernacular rendering, not verified
+; against any external Polish liturgical reference -- flagged here rather
+; than presented as sourced, the same honesty this file's own
+; `commemoration-of-st-peter` entry gives its own colour field above.
 ((id ef-adjustments)
   (directives
     ((Suppress vigil-of-christmas)
@@ -177,4 +258,11 @@
               (names
                 ((en "St. Peter") (pl "\197\155w. Piotra, Aposto\197\130a")))
               (rank Class3) (status Commemoration_only) (colour Red)
+              (subject Saint) (citations ()) (layer ef-universal)))))
+      (Add
+        ((date (Fixed (month 4) (day 25)))
+          (cel
+            ((slug major-litanies)
+              (names ((en "The Major Litanies") (pl "Litanie Większe")))
+              (rank Class4) (status Commemoration_only) (colour Violet)
               (subject Saint) (citations ()) (layer ef-universal))))))))