test,docs: RG110(c)'s adjacency is unobservable by construction

The re-review asked for a third commemoration in the shape-(c) row, so
that "spliced immediately after its trigger" could be told apart from
"appended at the end" -- it had proved an append-at-end variant passed
the whole suite green, the pair alone being too short to distinguish
them.

Attempting it establishes something better than the test requested. On
this day-shape a third commemoration is rubrically impossible. Shape (c)
requires the trigger to lose the day while still being admitted, and a
Class2 trigger can only lose to a I-class day (RG 111(a): one privileged
commemoration) or a II-class Sunday (RG 111(b): one, "scilicet de festo
II classis"). Both caps are one. The third candidate is now offered and
correctly refused, which is the assertion worth having.

So RG 110(c)'s "ante omnes alias commemorationes" half has no reachable
witness in the EF's rubrical space, and the re-review's own finding that
shape (c) never co-occurs with a third commemoration across 8417 years
is a consequence of the rubric rather than an accident of the data. The
append-at-end variant stays indistinguishable from the splice on every
input the engine can construct. Recorded rather than papered over with a
synthetic row proving a shape no rubric permits.

Also drops Record from the "nothing compares commemoration order" note
-- Record.t has no commemorations field at all -- and names, at
privilege_of's own (a) branch, that the Holy Name's Sunday privilege
currently rests on a substring match rather than on RG 17's closing
paragraph, which is its real warrant.

1 files changed, 17 insertions, 4 deletions

diff --git a/lib/rites/rite_ef/precedence_ef.ml b/lib/rites/rite_ef/precedence_ef.ml
index cd0c53b..5a2d307 100644
--- a/lib/rites/rite_ef/precedence_ef.ml
+++ b/lib/rites/rite_ef/precedence_ef.ml
@@ -514,7 +514,18 @@ let privilege_of (c : Vocab_ef.rank Precedence.candidate) : Precedence.privilege
   let is_temporal = c.Precedence.origin = Precedence.Temporal in
   let open Vocab_ef in
   (* (a) RG 109(a) (§4): "of a Sunday" -- the same slug marker RG 33's
-     [impedes_vigil] already reads to answer "is this candidate a Sunday". *)
+     [impedes_vigil] already reads to answer "is this candidate a Sunday".
+
+     FRAGILITY, named here because this is the decision point (fix-round
+     re-review, F5): [is_sunday_slug] is a SUBSTRING match, so the Holy Name
+     of Jesus obtains this privilege on its Sunday shape only because its
+     slug happens to read "ef-holy-name-sunday". That is a naming accident,
+     not a cited rule. The real warrant is RG 17's own closing paragraph
+     (quoted in full at temporal_ef.ml's [holy_name_sunday]): "Haec festa
+     locum tenent dominicae occurrentis cum omnibus iuribus et privilegiis"
+     -- these feasts hold the occurring Sunday's place WITH ALL ITS RIGHTS
+     AND PRIVILEGES, of which RG 109(a)'s privilege is one. A slug rename
+     would silently drop it while every test stayed green. *)
   if is_sunday_slug slug then Precedence.Privileged
   (* (b) RG 109(b) (§4): "of a I-class day" -- the candidate's own
      rank. In this codebase's current disposition rules the ONLY way a
@@ -1185,9 +1196,11 @@ let rg110_find_companion comms companion_slug =
    compares commemoration ORDER at all -- the lectio differential does not
    compare commemorations (its own "limit 1"); the oracle's own
    [identity_diff] sorts both sides into a multiset before comparing;
-   {!Colitur_kernel.Record}/`describe` (test_golden.ml) both sort their own
-   comms field too, for the same reason presence/identity checks should not
-   be order-sensitive by accident. This function's own [admit_cases] unit
+   and [describe] (test_golden.ml) sorts its own comms field too, for the
+   same reason presence/identity checks should not be order-sensitive by
+   accident. (CORRECTED, fix-round re-review: this previously also named
+   {!Colitur_kernel.Record}. Record.t has NO commemorations field at all --
+   see record.mli -- so it neither sorts nor carries them.) This function's own [admit_cases] unit
    test (test_precedence_ef.ml) is therefore the ONLY place in this
    codebase's test suite where commemoration order is asserted at all --
    flagged here, and in CLAUDE.md's own "know what each layer cannot see"