kernel+ef: fix round 1 -- lectionary caller-supplied, not eager

Critical (coordinator review): a clean `dune build` produced a `colitur`
that died at startup on EVERY subcommand, including ones touching no
lectionary data at all. Root cause was two-fold: data/ef/lectionary.sexp was
never added to the root default-build alias (only materialised as a side
effect of the test suite's own deps, which is why every check in the prior
report passed), and Rite_ef.context loaded it as a module-init side effect
via failwith, undoing Lectionary.load's own "never raises" promise at a
point no caller could catch.

Fixed structurally: Rite_ef.context is now a function taking ~lectionary,
Lectionary_ef.readings takes ~lectionary, and neither touches the filesystem
any more -- the same caller-supplied discipline the sanctoral layer already
had, restoring rite_ef.mli's own pre-existing claim about it and leaving a
seam for a future diocesan lectionary overlay. bin/main.ml grows
load_ef_lectionary, a sibling of load_ef_layer, routed through the same
colitur: %s / exit 2 path. data/ef/lectionary.sexp added to the root default
alias. Every caller of Rite_ef.context updated to supply it.

Also: two new tests that genuinely distinguish chain step 1 from step 2
(19 March 2026, Joseph's own proper over a competing temporal entry; 13
January 2030, Holy Family reached only through the temporal slug, the
Baptism entirely absent) -- the prior two tests both survived swapping the
chain order. Both new pins verified directly against the real data. The
chain's own comment now states plainly that its warrant is lectio's observed
behaviour, not a confirmed Missal citation, per the rules register's own
open item.

1 files changed, 18 insertions, 0 deletions

diff --git a/lib/rites/rite_ef/lectionary_ef.mli b/lib/rites/rite_ef/lectionary_ef.mli
index fe9359e..65fbfe5 100644
--- a/lib/rites/rite_ef/lectionary_ef.mli
+++ b/lib/rites/rite_ef/lectionary_ef.mli
@@ -3,11 +3,29 @@ open Colitur_kernel
 (** The EF lectionary resolution chain. All rubric knowledge about what a day
     with no proper falls back to lives here, not in the kernel.
 
+    [lectionary] is caller-supplied, not loaded by this module -- the same
+    reasoning rite_ef.mli's own [context] doc comment already gives for why
+    the sanctoral {!Colitur_kernel.Layer.t} stays a separate argument rather
+    than an embedded field: it lets a caller load data/ef/lectionary.sexp
+    however suits it, and leaves room for a future diocesan/proper
+    lectionary overlay to attach without this module changing at all.
+
+    An eager filesystem read at module initialisation was tried first and
+    reverted (fix round 1, coordinator review): [readings] used to close
+    over a [lectionary] value loaded as a side effect of this module being
+    LINKED, so `colitur easter <year>` -- which touches no lectionary data
+    at all -- died at startup the moment data/ef/lectionary.sexp was
+    missing from a bare `dune build`'s own default target (it was only
+    present because test/dune's own deps happened to materialise it,
+    masking the gap in every test run). See the task report for the
+    reproduction.
+
     Steps 1 and 2 only (Task 4): the observed celebration's own proper, else
     the day's own temporal slug in the lectionary. A day matching neither
     gets [] for now -- the ferial fallback to the preceding Sunday (Task 5)
     and the Commons (Task 6) are not built here. *)
 val readings :
+  lectionary:Lectionary.t ->
   observed:Vocab_ef.rank Celebration.t ->
   temporal:(Vocab_ef.season, Vocab_ef.rank) Temporal.t ->
   date:Date.t ->