merge: RG 33's third omission trigger

The last unbuilt clause in the EF module. A II/III-class vigil is omitted
entirely when the feast it precedes fails to keep its own day -- 1 744 days
across 1583-9999, three verified shapes, zero unexplained.

Rule and vigil inventory independently confirmed by O'Connell 1964, outside
the Divinum Officium -> missalemeum -> lectio lineage. The 10 affected days
in 2005-2050 are allow-listed as C39; no external day-level witness exists,
which the note states rather than glosses.

1 files changed, 40 insertions, 0 deletions

diff --git a/lib/kernel/precedence.mli b/lib/kernel/precedence.mli
index 09376d7..a0b4b1a 100644
--- a/lib/kernel/precedence.mli
+++ b/lib/kernel/precedence.mli
@@ -86,6 +86,46 @@ type ('s, 'r) rules = {
           own module documentation (Rite_ef.Precedence_ef.admit); stated
           here because this signature -- not any one rite's implementation
           of it -- is what an author of the next rite reads. *)
+  vigil_feast : 'r candidate -> Slug.t option;
+      (** The feast this candidate is a VIGIL OF, when the rite subjects that
+          vigil to omission because its feast did not keep its own day;
+          [None] for every other candidate, which is what a rite with no such
+          rule returns unconditionally.
+
+          Exists for RG 33's third omission trigger -- "vel si festum cui
+          praemittitur in alium diem transferri aut ad commemorationem reduci
+          contingat", "or if the feast it precedes happens to be transferred
+          to another day or reduced to a commemoration". Both halves of that
+          clause reduce to ONE observable question, which is why this hook
+          returns a slug rather than a verdict: is the named feast the
+          OBSERVED office on the following day? {!Calendar} asks it and
+          suppresses the vigil when the answer is no. A feast transferred away
+          (RG 96) and a feast outranked into a bare commemoration (RG 94) both
+          fail that test; so does a feast omitted outright, which RG 33 does
+          not enumerate but which is strictly the stronger case.
+
+          WHY THE RITE NAMES THE FEAST. The kernel could not infer it. RG 34
+          fixes the vigil on the day BEFORE its feast, so the date is known,
+          but nothing in {!Celebration.t} links the two and the slugs do not
+          reliably derive from one another -- in the EF's own shipped data
+          only two of five vigils ("ef-ascension-vigil"/"ef-ascension",
+          "vigil-of-sts-peter-paul"/"sts-peter-paul") share a stem, while
+          "vigil-of-st-lawrence" precedes "lawrence" and
+          "vigil-of-the-assumption" precedes
+          "assumption-of-the-blessed-virgin-mary". Deriving the feast by
+          string surgery would be wrong for three of the five. Asking "is a
+          Class1 sanctoral office observed tomorrow?" would be a PROXY, and
+          would fire on a day where some UNRELATED I-class feast had
+          transferred in on top of the real one -- the vigil's feast would be
+          absent and the vigil wrongly kept.
+
+          CALLED ONCE PER CANDIDATE PER DAY, and the resolution of the
+          following day that {!Calendar} performs to answer it does NOT
+          itself apply this rule. That is not an approximation: a vigil is a
+          candidate only on its own day, never on its feast's, so suppressing
+          it cannot change what is observed the day after. The check is
+          therefore a single pass with no fixed point and no recursion --
+          unlike RG 96's transfers, which genuinely need one. *)
 }
 
 (** The outcome of resolving one day's candidates. *)