feat(ef): implement RG 33's third omission trigger

RG 33 omits a II/III-class vigil in three cases: it falls on a Sunday, it
falls on a I-class feast, "vel si festum cui praemittitur in alium diem
transferri aut ad commemorationem reduci contingat". Only the first two
were built; the third was recorded in precedence_ef.ml as unimplemented on
the grounds that no witness existed in the shipped data. That reasoning was
wrong, and the rule fires on 1 744 days across 1583-9999.

Both halves of the clause reduce to one observable question -- is the feast
the OBSERVED office on the following day (RG 34 puts it there) -- so the
kernel asks it once per candidate, after place_transfers has settled the
year. No fixed point is needed: a vigil is a candidate only on its own day,
never on its feast's, so suppressing it cannot change what the next day
observes. Precedence.rules gains vigil_feast, which returns the slug of the
feast a vigil precedes; the kernel cannot infer that itself, because only
two of the five vigil/feast pairs share a slug stem.

Blast radius, measured pre-change binary vs HEAD over the whole domain and
classified: 1 744 days, three shapes, zero unexplained. 1 199 are the feast
reduced to a commemoration (10 August on a Sunday, St Lawrence); 478 and 67
are the feast transferred under RG 96 after the Sacred Heart or Corpus
Christi takes its day. The Assumption's and the Ascension's vigils never
qualify -- their I-class feasts always keep their own day.

Independently witnessed, which is unusual here. The published Ordo -- the
only witness outside the Divinum Officium -> missalemeum -> lectio lineage
-- omits St Lawrence's vigil on 2025-08-09, agreeing with colitur against
both engines. That date had been read earlier as an Ordo gap; the Ordo was
right, and correcting the misreading is what surfaced this clause. On
2027-08-09 the feast does keep its day and the Ordo omits a vigil colitur
correctly keeps, which is a genuine Ordo gap.

Allow-lists: C39 (lectio, 10 rows) and a 2038 oracle class citing the
register, the 2026-2027 window having no instance. The golden pin asserting
St Lawrence's vigil is violet moved 2025 -> 2027; its own comment had
reasoned about the vigil's weekday and missed that RG 33 also looks at the
feast's. Two new pins cover both shapes of the clause.

The vigil/feast table is built with Slug.of_string_exn: mutation testing
showed that of_string plus Result.to_option turns a typo into None, which
this hook's contract reads as "not a vigil", switching the rule off in
silence. Two tests assert the table against the shipped data in both
directions.

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. *)