cli: colitur day <year> dumps resolved liturgical days

Assembles Rite_ef.context (lib/rites/rite_ef/rite_ef.ml[i]): temporal,
anchors and vocab from Temporal_ef; rules from Precedence_ef's band,
disposition and admit; season_runs = Vocab_ef.seasons; transfer_target
newly implemented here.

transfer_target (RG 96): the next following day that is not I or II
class, with the Annunciation's own exception (Monday after Low Sunday).
Terminates by a structural step bound on its internal search, independent
of Calendar's own round guard, which bounds rounds across a year, not one
call's walk; documented as an obligation on rite.mli's transfer_target
field, which did not previously state it.

Fixes the vigil-naming mismatch Task 7's review predicted: the sanctoral
bootstrap names its vigils with a vigil-of-X prefix (lectio's own
convention), while Precedence_ef's is_vigil only recognised the temporal
cycle's own X-vigil suffix. Both are now recognised, fixing RG 91 entries
21/26 and RG 33's vigil omission for the four affected celebrations.
Verified by unit test and by mutation-testing the fix (reverting it fails
exactly the new rows) and against real output across several years.

Suppresses data/ef/sanctoral.sexp's vigil-of-christmas via a new overlay,
data/ef/adjustments.sexp: it is the same celebration as the temporal
cycle's own ef-nativity-vigil, both dated 24 December.

colitur day <year>: one line per civil-year day, temporal and sanctoral
fully resolved through Layer, Overlay, Precedence_ef and Calendar -- the
first CLI path exercising the whole Plan 3 pipeline against real data.
Verified the All Souls transfer chain (Tasks 7-8-11) end to end against
real output for both a Sunday year (2025, lands on 3 Nov) and a
non-Sunday year (2026, observed directly on 2 Nov).

1 files changed, 21 insertions, 1 deletions

diff --git a/lib/kernel/rite.mli b/lib/kernel/rite.mli
index 6d12dd4..ffe9471 100644
--- a/lib/kernel/rite.mli
+++ b/lib/kernel/rite.mli
@@ -38,5 +38,25 @@ type ('s, 'r) t = {
           Low Sunday (searching onward from there only if that day is itself
           blocked). [occupant] is supplied rather than a raw layer/temporal
           pair so the rite never has to re-implement occurrence resolution
-          just to answer "what sits here". *)
+          just to answer "what sits here".
+
+          OBLIGATIONS (not enforced by the type, and {!Calendar}'s own
+          termination argument depends on both): the result must be
+          {b strictly later} than the [Date.t] argument (the date the
+          candidate was impeded on) -- {!Calendar}'s placement pass treats
+          [target = origin] or [target < origin] as a legitimate placement,
+          not an error, so a rite whose search can stand still or go
+          backward would silently loop candidates in place or resurrect an
+          already-superseded occupant rather than failing loudly. The call
+          must also {b terminate} on its own: {!Calendar}'s round guard
+          (calendar.ml's [max_transfer_rounds]) bounds how many ROUNDS the
+          whole-year placement pass takes, which is a distinct, outer thing
+          from whatever internal search a single call to this function runs
+          -- an implementation that walks forward day by day looking for an
+          admissible date, without its own bound, can hang the caller
+          outright on a rite/data shape it does not handle, never reaching
+          the round guard at all. See rite_ef/precedence_ef.ml's
+          [transfer_target] for a concrete termination argument (a
+          structural step bound, not an appeal to the real calendar's own
+          structure). *)
 }