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.

2 files changed, 104 insertions, 5 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))))))))
diff --git a/data/ef/expected-divergences-missalemeum.sexp b/data/ef/expected-divergences-missalemeum.sexp
index 1fce257..96d6405 100644
--- a/data/ef/expected-divergences-missalemeum.sexp
+++ b/data/ef/expected-divergences-missalemeum.sexp
@@ -168,9 +168,9 @@
  (note "missalemeum, like lectio, computes no Rogation day at all and shows the plain paschaltide-week feria instead. Only 3 May 2027 (Rogation Monday) shows it in this window -- every other Rogation day here is won outright by a saint on both sides, so only the underlying temporal identity differs, which this comparator's axes do not expose.")
  (expected_rows 1))
  ((id M5)
- (citation "RG 80 (Major Litanies, 25 April) -- register §6's own pre-existing open item, \"Major Litanies (25 April, RG 80) are not computed\"")
- (verdict missalemeum)
- (note "Independently confirmed by the oracle, not a new finding: missalemeum's \"Pro rogationibus\" commemoration on St Mark's day (25 April, the Major Litanies' fixed date) is exactly the missing office register §6 already tracks. Only 2026 shows as a comparator MISMATCH: 25 April 2026 is a Saturday with Mark winning outright, so colitur's commemoration list is empty where the oracle's carries \"Pro rogationibus\" -- a real presence gap. 25 April 2027 is a Sunday: the Sunday wins on BOTH sides, and each side's own single commemoration slot goes to a DIFFERENT candidate (colitur: St Mark himself, an ordinary II-class sanctoral loser admitted under RG111(b)'s \"de festo II classis\" slot; missalemeum: the Major Litanies) -- both non-empty, same count, so this comparator's count-only axis (deliberately not slug-identity, see test_oracle.ml's own header) cannot see that mismatch; the underlying gap is the same, just invisible to this year's row.")
+ (citation "RG 80/81 (Major Litanies, Caput X \"De Litaniis maioribus et minoribus\") + RG 109(f) (Caput XVI \"De Commemorationibus\") -- now BUILT (ef-major-litanies task): Rite_ef.Precedence_ef's own [major_litanies_slug]/[disposition]/[privilege_of]/[transfer_target], data/ef/adjustments.sexp's matching `Add` entry")
+ (verdict colitur)
+ (note "CORRECTED (ef-major-litanies task): this entry's own PRIOR text claimed missalemeum's single admitted commemoration on 25 April 2027 was \"the Major Litanies\" -- checked directly against the raw fixture row while adjudicating a new divergence this task found (test/fixtures/missalemeum-ef-2026-2027.txt, the 2027-04-25 line: \"...|IV Sunday after Easter|-|St. Mark|Pro rogationibus|1|sancti:04-25:2:r\") and found BACKWARDS: missalemeum's own [commemorations] field there is \"St. Mark\", and \"Pro rogationibus\" (the Litanies) is the one listed in [displaced]. A genuine source-fidelity slip in this entry's own prior authorship, corrected here; see [M20] below for the divergence this correction actually motivates (2027's own now-real colitur-vs-missalemeum disagreement, adjudicated separately with its own RG citation). This entry (M5) now covers only 25 April 2026 (the ordinary, non-Sunday shape -- Mark wins the day outright on both sides, uncontested): both engines now admit a commemoration there (colitur: major-litanies; missalemeum: \"Pro rogationibus\"), so PRESENCE agrees (the register §6 gap this entry used to track is closed), but the two engines name the same real-world observance in different registers -- colitur's own English descriptive name (data/ef/adjustments.sexp's own honestly-flagged, not-primary-sourced \"The Major Litanies\") against missalemeum's Latin-ish \"Pro rogationibus\" -- never going to match as literal strings, and not a rubric dispute: RG 80/81 prescribe no English title for this observance at all. The SAME declared comparator limit M15/M18 already document for a temporal-origin candidate's identity, hit here for a different structural reason (a real candidate on BOTH sides now, just two different vocabularies, not an unresolvable name). Identity-gated (test_oracle.ml's own [m5_commemoration_matches]): pins that colitur's own sole admitted commemoration really is [major-litanies], not merely that some [Comm_identity_mismatch] diff exists on this date, the same discipline M19's own identity guard already established.")
  (expected_rows 1))
  ((id M8)
  (citation "RG 109(a) (\"of a Sunday\" is always privileged) + RG 111(a) (\"I class: none save one privileged\")")
@@ -205,10 +205,21 @@
  ((id M18)
  (citation "test_oracle.ml's own header, \"COMMEMORATION IDENTITY\" section, restated for the OBSERVED axis (ef-rg112-rg110 task) -- not an RG citation, a comparator LIMIT: Rite_ef.Temporal_ef never sets an English [names] field on any candidate it builds, the SAME limit M15 already names for a commemoration, now visible for the OBSERVED day itself now that the observed-identity axis exists")
  (verdict unresolvable)
- (note "REVISED, ef-bvm-saturday task: 395 of the 730 days in this window now carry this shape alone (M1/M3/M16 absorb a further 4 where it fires ALONGSIDE their own pre-existing citation -- see each entry's own widened note; 395+4=399 is the axis's own full unresolved population, UNCHANGED from before this task -- only the SPLIT moved, since M2 (closed above, this task) used to separately absorb 22 of the 26 that used to be \"elsewhere\"). Before this revision the split was 373 alone / 26 elsewhere (373+26=399) -- CORRECTED, fix round 1 (coordinator finding 8) -- the full breakdown, precisely: of 730 days, 331 are RESOLVED (colitur's own observed celebration carries a name) -- 330 resolved-and-MATCHING, 1 resolved-and-MISMATCHED (M13, Joseph vs the Seven Sorrows, already its own entry above) -- and 399 are UNRESOLVED (colitur's own name is [None]), split between this entry's own 395 and the 4 absorbed elsewhere. The BLIND SPOT this axis exists to close, stated precisely: a TEMPORAL-origin observed day silently replaced by a DIFFERENT temporal-origin observed day of the SAME RANK AND COLOUR -- exactly the shape that hid Holy Family from every layer before this task (rank 2/white on both sides, purely coincidental). This count PIN is what stands guard against that population growing silently in either direction: an implementation change that made MORE days temporal-origin-and-unresolvable, or fewer, changes 373 and fails the pin, even though the axis itself cannot say WHICH specific day moved or why. The overwhelming majority of days whose observed celebration is TEMPORAL-origin (an ordinary Sunday, a feria, a movable named feast including Holy Family itself) never carry an English name on colitur's side -- not a rubric dispute and not a data gap either engine is wrong about, a LIMIT of this comparator, honestly counted rather than silently passed, per the brief's own explicit instruction (\"a day whose observed identity cannot be resolved must be a counted, allow-listed outcome, never a silent skip\"). Gated on the diff SHAPE alone (exactly, and only, observed-identity-unresolved), not a literal date list the way every other entry in this file is -- at this population size a date list would itself be the \"pattern that could silently widen\" this file's own header warns against, for the opposite reason a date RANGE is normally risky: the predicate (colitur's own resolved name is [None]) is the precise, falsifiable evidence, the same shape M2's own title-substring predicate already uses instead of enumerating dates, just keyed on presence-of-a-name rather than a title string. Building an English name onto every temporal-cycle candidate (a data/lectionary-bootstrap task, Plan 4, out of this task's scope -- register §6, the same open item M15's own note already tracks) would resolve this entry to Matched for every one of these days it does not instead expose as a REAL divergence (Holy Family's own two dates in this window, 2026-01-11 and 2027-01-10, are counted here, not separately -- the name comparison genuinely cannot distinguish \"Holy Family\" from any other unnamed Sunday, so proving Holy Family's own correctness rests on the golden pins and the differential's own C15, not this axis). Derived directly from the comparator's own failure output (test_layer_m_counts_match_citations), not hand-counted first and cross-checked after: 373.")
- (expected_rows 395))
+ (note "REVISED AGAIN, ef-major-litanies task: 394, down by exactly 1 from the ef-bvm-saturday task's own 395 (breakdown below unchanged in kind, only this one row moved). 25 April 2027 used to carry [Observed_identity_unresolved] ALONE (the Sunday itself is temporal-origin, unresolved; commemoration identity agreed by coincidence -- Mark on both sides, pre-Litanies) and so fell into this entry's own bucket; now that the Major Litanies are built, that same date ALSO carries [Comm_identity_mismatch] (colitur admits the Litanies, missalemeum still admits Mark -- see [M20]'s own new entry), so it moves OUT of this bucket and into M20's own single-row citation instead. Verified directly from the comparator's own failure output, not merely arithmetic (395-1=394 is necessary but not sufficient: the mechanism above is why it left, not merely that some count decreased).
+
+REVISED, ef-bvm-saturday task: 395 of the 730 days in this window used to carry this shape alone (M1/M3/M16 absorb a further 4 where it fires ALONGSIDE their own pre-existing citation -- see each entry's own widened note; 395+4=399 is the axis's own full unresolved population, UNCHANGED from before that task -- only the SPLIT moved, since M2 (closed above) used to separately absorb 22 of the 26 that used to be \"elsewhere\"). Before that revision the split was 373 alone / 26 elsewhere (373+26=399) -- CORRECTED, fix round 1 (coordinator finding 8) -- the full breakdown, precisely: of 730 days, 331 are RESOLVED (colitur's own observed celebration carries a name) -- 330 resolved-and-MATCHING, 1 resolved-and-MISMATCHED (M13, Joseph vs the Seven Sorrows, already its own entry above) -- and 399 are UNRESOLVED (colitur's own name is [None]), split between this entry's own (then 395, now 394) and the 4 absorbed elsewhere. The BLIND SPOT this axis exists to close, stated precisely: a TEMPORAL-origin observed day silently replaced by a DIFFERENT temporal-origin observed day of the SAME RANK AND COLOUR -- exactly the shape that hid Holy Family from every layer before the ef-rg112-rg110 task (rank 2/white on both sides, purely coincidental). This count PIN is what stands guard against that population growing silently in either direction: an implementation change that made MORE days temporal-origin-and-unresolvable, or fewer, changes this number and fails the pin, even though the axis itself cannot say WHICH specific day moved or why -- exactly the guard that caught this task's own -1 shift, which HAD to be traced to a specific date and mechanism (above) rather than merely re-baselined. The overwhelming majority of days whose observed celebration is TEMPORAL-origin (an ordinary Sunday, a feria, a movable named feast including Holy Family itself) never carry an English name on colitur's side -- not a rubric dispute and not a data gap either engine is wrong about, a LIMIT of this comparator, honestly counted rather than silently passed, per the brief's own explicit instruction (\"a day whose observed identity cannot be resolved must be a counted, allow-listed outcome, never a silent skip\"). Gated on the diff SHAPE alone (exactly, and only, observed-identity-unresolved), not a literal date list the way every other entry in this file is -- at this population size a date list would itself be the \"pattern that could silently widen\" this file's own header warns against, for the opposite reason a date RANGE is normally risky: the predicate (colitur's own resolved name is [None]) is the precise, falsifiable evidence, the same shape M2's own title-substring predicate already uses instead of enumerating dates, just keyed on presence-of-a-name rather than a title string. Building an English name onto every temporal-cycle candidate (a data/lectionary-bootstrap task, Plan 4, out of this task's scope -- register §6, the same open item M15's own note already tracks) would resolve this entry to Matched for every one of these days it does not instead expose as a REAL divergence (Holy Family's own two dates in this window, 2026-01-11 and 2027-01-10, are counted here, not separately -- the name comparison genuinely cannot distinguish \"Holy Family\" from any other unnamed Sunday, so proving Holy Family's own correctness rests on the golden pins and the differential's own C15, not this axis).")
+ (expected_rows 394))
  ((id M19)
  (citation "RG 110's OTHER direction: \"In Officio et Missa S. Petri semper fit commemoratio S. Pauli, ET VICISSIM\" -- the SAME rule M12 used to cite, applied here to Paul's own office commemorating Peter, not Peter's own office commemorating Paul; confirmed a third time by the calendarium's own June table, both photographic scans, word for word: \"In Commemoratione S. Pauli Ap., III classis. / Commemoratio S. Petri Ap.\"")
  (verdict colitur)
  (note "30 June, both years in this window (2026-06-30, 2027-06-30): colitur now shows +commemoration-of-st-peter (data/ef/adjustments.sexp's own `Add` directive) where missalemeum shows nothing at all -- not even Peter listed under \"displaced\", meaning missalemeum's own engine never constructs a candidate for this commemoration in the first place, the SAME shape this task found in lectio's own source data (`~/git/projects/lectio/internal/caldata/tridentine-calendar.ini` has no 06-30 companion entry either -- an upstream data gap both reference engines share, not a colitur bootstrap miss). Verdict colitur, the same shape as M1/M3/M8/M10 above (each already \"missalemeum does not implement X\"): the calendarium's own text is unconditional and confirmed on both photographic scans, and colitur's own machinery for the other two RG 110 pairs (25 January, 22 February) already produces the identical shape correctly. Diff shape [Comm_presence] alone: rank/colour/observed-identity all already agreed before this fix (the OBSERVED celebration on both dates is unchanged, `in-commemoratione-sancti-pauli-apostoli`, sanctoral-origin with a resolvable name matching missalemeum's own title exactly on both rows) -- only the new commemoration's PRESENCE is new, so identity comparison is never even reached (this file's own header: identity is only attempted once presence and count already agree). 2, one per year, independently re-derived against the fixture's own two 06-30 rows before being set here, not assumed from the citation's own two-pair symmetry.")
  (expected_rows 2))
+ ((id M20)
+ (citation "RG 109(f) + RG 111(b), Caput XVI \"De Commemorationibus\", CORROBORATED by RG 434(b) (\"VIII - De diversis Missae partibus\", \"D) De orationibus\", \"I - De orationibus in genere\"), added fix round 1 (F5) -- all primary-source-verified word for word, all three documents (docs/research/rules-register.md §4). RG 109(f): \"de Litaniis maioribus, in Missa\" -- in the SAME closed privileged list as (a)-(e). RG 111(b): \"in dominicis II classis, una tantum admittitur commemoratio, scilicet de festo II classis, QUAE TAMEN OMITTITUR SI COMMEMORATIO PRIVILEGIATA FACIENDA SIT.\" RG 434(b), WORD-IDENTICAL, but explicitly scoped to the MASS (\"post orationem Missae\"), which is exactly where RG 109(f)'s own privilege lives (\"in Missa\"): \"in dominicis II classis, nulla alia admittitur oratio, praeter commemorationem festi II classis, quae tamen omittitur si commemoratio privilegiata facienda sit.\" The second citation answers the objection that RG 111 sits among Office-and-Mass rubrics and might be read as Office-shaped: RG 434 cannot be so read, and says the identical thing.")
+ (verdict colitur)
+ (note "NEW (ef-major-litanies task). 25 April 2027: RG 80's own transfer condition (25 April = Easter Sunday or Monday) does NOT fire this year, so the Litanies stay on 25 April itself -- which this year happens to be an ordinary II-class Sunday (RG 91 entry 15). St Mark (II class, entry 16) also loses to the Sunday. Two losing candidates, ONE slot (RG 111(b)/RG 434(b)): colitur admits the Litanies, not Mark; missalemeum's raw fixture row shows the reverse (verified directly against test/fixtures/missalemeum-ef-2026-2027.txt's own 2027-04-25 line -- see [M5]'s own corrected note above for the exact text, which previously mis-transcribed this same row backwards). ADJUDICATED, not merely asserted: {!Precedence_ef.admit}'s [Class2, true] branch already implements RG 111(b)'s privilege-overrides-ordinary clause exactly as quoted above, and this project's own prior work (precedence_ef.ml's \"Fix, Task 16\" comment) already primary-source-verified that same clause independently of this task -- the Litanies winning here is the SAME mechanism, not a special case written for it; St Mark meets the fate any ordinary Class2 commemoration meets when a privileged one is also due (RG 16(a)'s Transfiguration/Sixtus shape is the nearest existing witness, though there the privileged side wins the whole DAY, not merely the commemoration slot).
+
+ SCOPE, made explicit (fix round 1, F5): RG 108 (\"Commemorationes privilegiatae fiunt in Laudibus et in Vesperis necnon in omnibus Missis; commemorationes vero ordinariae fiunt tantum in Laudibus, in Missis conventualibus et in omnibus Missis lectis\") + RG 81 (\"nihil fit in Officio, sed tantum in Missa\") together mean the Litanies' own privileged slot is due IN THE MASS specifically; nothing here computes or asserts a separate OFFICE-level answer for the same day. colitur emits ONE resolved day, not one per liturgical hour -- this adjudication, and every one of the 829 domain-wide Sunday-displacement days it governs, is the MASS answer. Defensible for a Mass-facing engine (this codebase's own stated scope, citations/readings, is Mass-oriented throughout), but stated here rather than left implicit, since it is what the whole adjudication rests on.
+
+ HONESTLY FLAGGED, now closer to certain than first written: this is the first real (non-synthetic) data point this codebase has for \"an ordinary Class2 feast and a privileged non-feast commemoration both losing to the identical Sunday\" -- every other witness for this admit branch in test_precedence_ef.ml is hand-built. First written \"moderate-high, not certain\"; RG 434(b)'s own independent, Mass-specific repetition of RG 111(b)'s exact rule (fix round 1 finding, above) closes the main remaining doubt (that RG 111 might be Office-shaped) and moves this near-certain -- but NOT to certain, and the revisit trigger stands: no primary text anywhere names the Major Litanies in a Mass-orations-count worked example, only the general II-class-Sunday rule, twice over. RG 434(b) closes the Office-shaped doubt and nothing further. If a future primary-source pass finds textual grounds narrowing RG 109(f)'s privilege specifically, THIS is the entry to revisit first. (That sentence was dropped in the same edit that raised the label to near-certain, and is restored here: upgrading a confidence while deleting its revisit trigger is the one move this record must not make.) missalemeum's divergence remains consistent with this project's already-documented pattern of RG 108-111 gaps in that oracle (M1, M8, M10 above each already \"missalemeum does not implement X\") -- plausibly one more instance of the same generator not modelling RG 109(f)'s privilege for this rare, single-date observance. Identity-gated (test_oracle.ml's own [m20_commemoration_matches]): pins that colitur's own sole admitted commemoration really is [major-litanies].")
+ (expected_rows 1))