data(ef): document why adjustments.sexp's directives survive the re-bootstrap

Neither of adjustments.sexp's two directives is a no-op after the
regeneration, and neither is removed -- reasoned through deliberately
rather than deleted on sight, per Overlay.apply's own documented
diagnostic behaviour (Edit has no "already correct" case; it unconditionally
folds every field_edit over the current value when the slug is present, no
diagnostic either way).

`Edit most-holy-name-of-mary (Set_subject Bvm)`: the base bootstrap no
longer needs this correction (the source dropped `class = lord` for this
slug, so the default is already Subject.Saint), but the overlay still
forces `Saint -> Bvm`. Kept for two reasons: data precision (the
calendarium's "Sanctissimi Nominis Mariae" title still argues for Bvm over
the generic Saint default, independent of what lectio's class field says)
and as a regression guard (Set_subject is unconditional, so it would also
correct a future re-introduction of `class = lord` for this slug, the one
subject value RG16(a) behaviourally reads).

`Suppress vigil-of-christmas`: re-verified, not assumed -- the slug is
still present, unchanged, in both the regenerated source and the
regenerated sanctoral.sexp, so the directive still fires its ordinary
slug-present path.

test_rite_ef.ml's own comment on the overlay-in-effect test previously
claimed the base file carries `subject Lord` for most-holy-name-of-mary,
which the regeneration made false; corrected in place rather than left
stale, per this project's own discipline around wrong claims.

1 files changed, 44 insertions, 0 deletions

diff --git a/data/ef/adjustments.sexp b/data/ef/adjustments.sexp
index 05ee401..68ab590 100644
--- a/data/ef/adjustments.sexp
+++ b/data/ef/adjustments.sexp
@@ -50,6 +50,50 @@
 ; the user's ruling resolves that disagreement in the oracle's favour for
 ; this codebase's own purposes, not by declaring the calendarium argument
 ; wrong. See register §6.0 for the full account of both sides.
+;
+; ef-rebootstrap (2026-08-12): both directives re-examined against the
+; regenerated source (tridentine-calendar.ini, SHA-256 1b303ef2...), which
+; independently fixed several of the same defects this file was written to
+; patch. Neither directive was removed -- reasoning below, per the task's
+; own instruction to decide deliberately rather than delete on sight.
+;
+; `Edit most-holy-name-of-mary` -- the base bootstrap no longer needs this
+; correction: the regenerated INI's own `[most-holy-name-of-mary]` section
+; has DROPPED its `class = lord` field entirely (confirmed by direct grep
+; against the source), so `tools/bootstrap_sanctoral.ml`'s `parse_subject`
+; now falls through to its own default, `Subject.Saint` -- not `Lord` --
+; before this overlay ever runs. Checked what {!Overlay.apply}'s [Edit]
+; actually does with a directive whose target slug is present but whose
+; field is no longer wrong, rather than assuming: [Edit] has no notion of
+; "already correct" -- it looks up the slug, and if found (as this one
+; still is) unconditionally folds every field_edit over the current value,
+; firing NO diagnostic either way (overlay.ml's [apply_directive], the
+; [Edit] branch: the only diagnostic is "slug not present", never "already
+; matches"). So this is not a no-op: it still forces `Saint -> Bvm` on
+; every run, identically to before, just starting from a different base
+; value than it used to. Decision: KEEP, for two independent reasons, not
+; one -- (1) DATA PRECISION, unaffected by the base bootstrap's own fix:
+; the calendarium's "Sanctissimi Nominis Mariae" title names Mary
+; specifically, so [Bvm] remains the more accurate tag than the generic
+; [Saint] default, on the same textual grounds as the original entry
+; above, regardless of what lectio's own `class` field happens to say this
+; week. (2) REGRESSION DEFENCE: because [Set_subject] is unconditional, it
+; also now stands as a guard against `class = lord` ever being
+; RE-introduced for this slug by a future lectio regeneration -- the
+; overlay would still force the result away from [Lord] (the one subject
+; value {!Precedence_ef.band}'s RG 16(a) branch behaviourally reads),
+; rather than silently letting a re-introduced bootstrap defect through.
+; Removing the directive now would trade a currently-harmless redundancy
+; for the loss of that guard.
+;
+; `Suppress vigil-of-christmas` -- re-verified, not assumed: `[vigil-of-
+; christmas]` (24 Dec) is still present, unchanged, in both the
+; regenerated INI and the regenerated `data/ef/sanctoral.sexp` (still the
+; same duplicate of `rite_ef/temporal_ef.ml`'s own `ef-nativity-vigil`
+; this directive was written to remove), so `Layer.mem` still finds it and
+; {!Overlay.apply}'s [Suppress] branch still fires its ordinary
+; slug-present path (no diagnostic) exactly as before. Nothing about this
+; regeneration touched the reason this directive exists; kept unchanged.
 ((id ef-adjustments)
   (directives
     ((Suppress vigil-of-christmas)