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, 15 insertions, 5 deletions

diff --git a/lib/rites/rite_ef/rite_ef.mli b/lib/rites/rite_ef/rite_ef.mli
index 710db1d..1a4c715 100644
--- a/lib/rites/rite_ef/rite_ef.mli
+++ b/lib/rites/rite_ef/rite_ef.mli
@@ -25,9 +25,10 @@ module Lectionary_ef = Lectionary_ef
     - [transfer_target]: {!Precedence_ef.transfer_target}, RG 96 (see that
       value's own documentation for the termination and forward-progress
       argument {!Colitur_kernel.Rite.t.transfer_target}'s contract requires).
-    - [readings]: {!Lectionary_ef.readings} -- the observed celebration's own
-      proper, else the day's own temporal slug in data/ef/lectionary.sexp
-      (chain steps 1-2; the ferial fallback and the Commons are later work).
+    - [readings]: {!Lectionary_ef.readings} partially applied to the caller's
+      own [~lectionary] -- the observed celebration's own proper, else the
+      day's own temporal slug in data/ef/lectionary.sexp (chain steps 1-2;
+      the ferial fallback and the Commons are later work).
 
     Deliberately carries no [sanctoral]/[lectionary] fields the way the
     original design-doc sketch of [RITE] does: {!Colitur_kernel.Rite.t} (the
@@ -35,5 +36,14 @@ module Lectionary_ef = Lectionary_ef
     a separate argument to {!Colitur_kernel.Calendar.year}/[day] rather than
     embedding it here, so a caller can load data/ef/sanctoral.sexp (plus
     data/ef/adjustments.sexp's overlay) however suits it -- bin/main.ml's
-    [load_ef_layer] is the one this module ships with. *)
-val context : (Vocab_ef.season, Vocab_ef.rank) Colitur_kernel.Rite.t
+    [load_ef_layer] is the one this module ships with. [~lectionary] here is
+    the exact same discipline (fix round 1, coordinator review: [context]
+    used to be a plain value that loaded data/ef/lectionary.sexp as a side
+    effect of {!Lectionary_ef} being linked, which broke every subcommand
+    that never touches lectionary data at all the moment that file was
+    missing from a bare build -- see the task report). A future
+    diocesan/proper lectionary overlay has a caller-side seam to attach to
+    for the same reason the sanctoral overlay already does. *)
+val context :
+  lectionary:Colitur_kernel.Lectionary.t ->
+  (Vocab_ef.season, Vocab_ef.rank) Colitur_kernel.Rite.t