fix(ef): days within the Octave of the Nativity, and RG 69 for 29-31 Dec

M11 was the one entry in the missalemeum allow-list adjudicated against
colitur, and it was right to be. The calendarium directs "Com. octavae
Nativitatis" under each of 26, 27 and 28 December (LT.txt:5454-5459) and
RG 109(c) makes a commemoration of the days within the Octave privileged.
colitur emitted none.

The cause was a reasoning error stated in Temporal_ef's own comment:
"26-28 Dec are Stephen, John and the Innocents, hence sanctoral". Their
office is sanctoral -- those II-class feasts win the day -- but they
remain days WITHIN the Octave (RG 67, "Dies infra octavam sunt II
classis"), and colitur built them as generic Class4 ferias. With no
octave-day candidate there was nothing for the feast to be commemorated
over. Building days 2-4 exactly as days 5-7 always were makes the
commemoration fall out of the existing machinery rather than needing a
special case: the feast wins on rank, the octave day loses, RG 109(c)
privileges it, RG 111(c)'s single slot goes to it.

A second, independent defect surfaced while fixing it. The octave-day
branch covered 29-31 December unconditionally, so a Sunday falling there
got a feria identity -- where RG 69 says a Sunday occurring 26-31
December SEMPER keeps its own office and commemorates the feast.
Confirmed against the oracle rather than argued: missalemeum shows
"Sunday in the Octave of Christmas" on 2035-12-30, a Sunday, where
colitur showed a feria. Both named and anchors now exclude Sundays;
anchors had asserted the octave slugs unconditionally and was wrong the
same way.

Blast radius, full sweep against the pre-change binary: 25251 days, every
one 26-31 December, exactly two shapes, zero unclassified -- 21653
carrying an octave-day slug and 3598 that are all Sundays, the RG 69
correction.

Allow-lists: M11 closed and removed. C6 narrowed 138 to 119, nineteen of
its days having changed temporal identity rather than verdict. M15
widened 18 to 22 -- both streams now commemorate the octave, but the
candidate is temporal-origin and carries no English name to match against
missalemeum's own, this entry's documented limit on four more dates.

Stated rather than glossed: this trades a substantive divergence, colitur
omitting a commemoration the Missal directs, for a comparator limit, the
commemoration existing but not being name-matchable. That is a real
improvement, but what the oracle now proves is that both streams
commemorate something on those days; the identity rests on the rubric and
the calendarium.

Register: section 6.17.

1 files changed, 33 insertions, 3 deletions

diff --git a/lib/rites/rite_ef/precedence_ef.ml b/lib/rites/rite_ef/precedence_ef.ml
index c9e6a55..dd75765 100644
--- a/lib/rites/rite_ef/precedence_ef.ml
+++ b/lib/rites/rite_ef/precedence_ef.ml
@@ -1325,9 +1325,39 @@ let disposition ~(winner : Vocab_ef.rank Precedence.candidate)
    accurate, already decides every real case this codebase's current data
    produces; the slug fallback below is exercised only between two
    [Commemoration_only] candidates tied at {!unclassified} (138 of the 599,
-   all order/count-invisible -- RG 91 has no table position for either of
-   them to compare, so there is nothing more specific RG 113 could supply
-   here either). {!band} needs a [context] this function itself does not
+   RG 91 having no table position for either of them to compare).
+
+   CORRECTED 2026-08-18: this used to add "all order/count-invisible", which
+   was true of 2005-2050 -- the range it was measured over -- and is NOT true
+   generally. 2038-06-02 is a live counter-example, found when the 2035/2038
+   oracle windows began comparing commemorations: the Ascension Vigil is II
+   class, RG 111(c) admits exactly ONE commemoration, and the two candidates
+   are `rogation-wednesday` and `sts-marcellinus-peter-erasmus` -- both
+   genuinely [Commemoration_only] (2 June reads "Commemoratio ... Comm." in
+   the calendarium itself, LT.txt:5148 and scan1.txt:2828, so the data is
+   right, not defective). The slug fallback therefore decides which
+   commemoration the day KEEPS, not merely how two kept ones are ordered.
+   missalemeum keeps the saints; this keeps the Rogation, on nothing but
+   "rogation-" sorting before "sts-".
+
+   AND THE RUBRIC GENUINELY DOES NOT SETTLE IT, checked rather than assumed.
+   RG 113's second sentence needs a table position and neither has one. Its
+   FIRST sentence, "Commemoratio de Tempore fit primo loco", looked like the
+   answer -- a Rogation being plausibly *de Tempore* -- but RG 81 forecloses
+   it in terms: "De Litaniis maioribus ... Earum autem commemoratio NON EST
+   HABENDA commemoratio «de Tempore»" (LT.txt:1399-1401), and RG 89 extends
+   RG 81 to the minor Litanies. So a Rogation commemoration is explicitly not
+   *de Tempore*, and tagging the entry [Subject.Temporal] to reach that
+   sentence would have been WRONG -- the [Subject.Saint] it carries,
+   inherited from the Major Litanies precedent, stands. RG 114 says only that
+   what exceeds the number is omitted, never which.
+
+   What remains is therefore a genuine LACUNA, not an unfound rule: the slug
+   order below is a documented CONVENTION for a case the Rubricae Generales
+   leave open, deliberately kept rather than changed to match the oracle --
+   which would be adopting an answer with no more warrant than this one, from
+   a source already adjudicated wrong six times over. See
+   docs/research/rules-register.md §6.16. {!band} needs a [context] this function itself does not
    have (date/season/weekday) -- unlike [dignity], which read [rank] alone
    -- so {!Precedence.resolve} now computes each candidate's own [band]
    value once, generically, and hands it to [admit] as the trailing [int]