kernel+rite-ef: correct stale plan-relative deferrals (item 7, part 2)

Several comments described work as "arriving with Plan 3" or "waiting
for Plan 3" that either shipped without it or refer to the wrong future
plan number, all now false in ways that would mislead the next reader:

- temporal_ef.ml (two places) and precedence_ef.ml said the Major
  Litanies (25 April, RG 80) "arrive with Plan 3's sanctoral". Plan 3
  shipped, in this branch, without them; register §6 tracks this as a
  plain open item with no plan committed to build it, and now says so.
- temporal_ef.ml said the Sacred Triduum's "own named offices are a Plan
  3 sanctoral addition". Wrong on two counts: Plan 3 shipped without
  adding them, AND a proper office for I-class FERIAS was never a
  sanctoral matter in the first place (RG 21 defines "feria" to exclude
  Sundays/feasts, not the reverse). 2026-04-02/03/04 still resolve to the
  ordinary Passiontide ferial fallback's own generic slugs
  (ef-passiontide-2-{thursday,friday,saturday}), confirmed against real
  output; register §6 now records this as its own open item.
- temporal_ef.ml said the Rogation-Wednesday commemoration (Ascension
  Vigil day, entry 21) "waits for RG 108-111" -- both the precedence
  framework and RG 108-111 exist now; the Wednesday's own commemoration
  is still never constructed, but for a different, still-real reason (no
  candidate is wired for it), not a forward dependency. Fixed at both of
  this comment's two occurrences in the file.
- vocab.ml/vocab.mli's `seasons` field doc said "Validate's contiguity
  check reads this" -- false since validate.ml's "seasons" check switched
  to Rite.t.season_runs in this branch (rite-supplied, to support a
  season appearing in more than one run, which the modern form's Ordinary
  Time needs and EF does not).
- vocab.ml/vocab.mli's `ranks` field doc said "it is not a precedence
  relation until Plan 3 defines one" -- Plan 3 did define one (RG 111's
  dignity ordering), but as its own small, separately-hardcoded function
  in precedence_ef.ml, not one derived from this field; corrected to say
  so precisely rather than leaving a forward-looking claim unresolved.
- The lectionary bootstrap (reading citations, Liturgical_day.t's own
  `citations` field) is called "Plan 3" at slug.ml, vocab_ef.ml, and
  three places in temporal_ef.ml, but "Plan 4" at liturgical_day.mli
  (whose own doc comment -- "always empty until Plan 4" -- is the
  authoritative one: the SANCTORAL bootstrap is Plan 3 and shipped; the
  LECTIONARY bootstrap is a separate, later Plan 4). All six corrected to
  say Plan 4, cross-referencing the Plan 3/4 distinction at the first
  (slug.ml) occurrence so the reasoning is not duplicated six times.

No behaviour change: every edit here is a comment/documentation
correction. Verified byte-identical `colitur day` output across 1583,
1900, 1902, 2008, 2011, 2026, 2038, 9999. 259/259 tests green.

3 files changed, 50 insertions, 8 deletions

diff --git a/lib/kernel/slug.ml b/lib/kernel/slug.ml
index 5139c99..25281f2 100644
--- a/lib/kernel/slug.ml
+++ b/lib/kernel/slug.ml
@@ -1,6 +1,10 @@
 (* Stable celebration identifiers. Also the lectionary key: EF slugs are adopted
-   verbatim from lectio so the Plan 3 lectionary bootstrap needs no mapping
-   table (spec §4.4). *)
+   verbatim from lectio so the Plan 4 lectionary bootstrap needs no mapping
+   table (spec §4.4). CORRECTED (final fix wave, item 7): this comment said
+   "Plan 3" -- the SANCTORAL bootstrap (data/ef/sanctoral.sexp) is Plan 3 and
+   shipped in this branch; the LECTIONARY bootstrap (reading citations,
+   Liturgical_day.t's own [citations] field) is a separate, later Plan 4,
+   per that field's own doc comment ("always empty until Plan 4"). *)
 type t = string
 
 let valid_char c = (c >= 'a' && c <= 'z') || (c >= '0' && c <= '9') || c = '-'
diff --git a/lib/kernel/vocab.ml b/lib/kernel/vocab.ml
index 78729bb..bcb48b8 100644
--- a/lib/kernel/vocab.ml
+++ b/lib/kernel/vocab.ml
@@ -7,13 +7,32 @@
    parametric types natively. *)
 type ('s, 'r) t = {
   seasons : 's list;
-      (** canonical liturgical-year order; Validate's contiguity check reads this *)
+      (** canonical liturgical-year order. CORRECTED (final fix wave, item
+          7): this used to say "Validate's contiguity check reads this" --
+          false since validate.ml's own "seasons" check switched to
+          {!Colitur_kernel.Rite.t}.season_runs in this branch (Plan 2
+          carried item 1: EF has each season in one run, but the modern
+          form's Ordinary Time does not, so the expected run sequence had
+          to become rite-supplied rather than derived from this field).
+          For EF specifically {!Rite_ef.rite_ef.ml} sets season_runs to
+          this very list, so the two happen to agree there, but Validate
+          itself no longer reads [seasons] to build its expectation. *)
   season_to_string : 's -> string;
   season_of_string : string -> 's option;
   ranks : 'r list;
       (** documentation order, highest first. Plan 2 uses it only for the
-          closure check -- it is not a precedence relation until Plan 3
-          defines one. *)
+          closure check. CORRECTED (final fix wave, item 7): this used to
+          say "it is not a precedence relation until Plan 3 defines one" --
+          Plan 3 did define one (RG 111's dignity ordering, Rite_ef.
+          Precedence_ef.dignity/compare_dignity), but as its OWN small,
+          separately-hardcoded function, not one derived from this field:
+          [admit] needs Vocab_ef.rank's dignity as plain data (RG 8's four
+          classes), and reusing this field's own [int list] position would
+          couple that meaning to documentation order the way {!band} is
+          explicitly NOT allowed to (precedence_ef.ml's own file comment).
+          This field therefore still carries no precedence relation of its
+          own; a rite that wanted one derived from it would have to build
+          it itself. *)
   rank_to_string : 'r -> string;
   rank_of_string : string -> 'r option;
 }
diff --git a/lib/kernel/vocab.mli b/lib/kernel/vocab.mli
index 78729bb..bcb48b8 100644
--- a/lib/kernel/vocab.mli
+++ b/lib/kernel/vocab.mli
@@ -7,13 +7,32 @@
    parametric types natively. *)
 type ('s, 'r) t = {
   seasons : 's list;
-      (** canonical liturgical-year order; Validate's contiguity check reads this *)
+      (** canonical liturgical-year order. CORRECTED (final fix wave, item
+          7): this used to say "Validate's contiguity check reads this" --
+          false since validate.ml's own "seasons" check switched to
+          {!Colitur_kernel.Rite.t}.season_runs in this branch (Plan 2
+          carried item 1: EF has each season in one run, but the modern
+          form's Ordinary Time does not, so the expected run sequence had
+          to become rite-supplied rather than derived from this field).
+          For EF specifically {!Rite_ef.rite_ef.ml} sets season_runs to
+          this very list, so the two happen to agree there, but Validate
+          itself no longer reads [seasons] to build its expectation. *)
   season_to_string : 's -> string;
   season_of_string : string -> 's option;
   ranks : 'r list;
       (** documentation order, highest first. Plan 2 uses it only for the
-          closure check -- it is not a precedence relation until Plan 3
-          defines one. *)
+          closure check. CORRECTED (final fix wave, item 7): this used to
+          say "it is not a precedence relation until Plan 3 defines one" --
+          Plan 3 did define one (RG 111's dignity ordering, Rite_ef.
+          Precedence_ef.dignity/compare_dignity), but as its OWN small,
+          separately-hardcoded function, not one derived from this field:
+          [admit] needs Vocab_ef.rank's dignity as plain data (RG 8's four
+          classes), and reusing this field's own [int list] position would
+          couple that meaning to documentation order the way {!band} is
+          explicitly NOT allowed to (precedence_ef.ml's own file comment).
+          This field therefore still carries no precedence relation of its
+          own; a rite that wanted one derived from it would have to build
+          it itself. *)
   rank_to_string : 'r -> string;
   rank_of_string : string -> 'r option;
 }