Merge branch 'ef-rg16a': RG 16(a), RG 111(b), RG 113, and commemoration identity

Closes the largest known-wrong-output item on record (RG 16(a): a Feast
of the Lord occurring on a II-class Sunday leaves the Sunday
uncommemorated -- 5996 wrong days over 1583-9999) together with RG
111(b)'s rank floor on the day it holds, and gives the oracle layer the
ability to compare commemoration identity rather than only presence and
count.

Also corrects a methodological defect that had produced wrong rulings in
both this project and its sibling: docs/research/ holds an electronic
transcription alongside two photographic scans, and the transcription
silently drops commemoration lines -- seven across the year. Reasoning
from its silence had convicted the oracle wrongly on 14 August and
ruled a genuine 9 August commemoration spurious. The scans are the
primary source; the rule is now recorded at the top of the register.

RG 113 replaces an alphabetical same-rank tie-break that had no
rubrical warrant. A bare Commemoratio has no row in RG 91's table at
all, so band no longer hands one the entry of a III-class universal
feast: 4451 days, all four reordered pairs verified against a
photographic scan, zero observed-day changes.

1 files changed, 18 insertions, 8 deletions

diff --git a/lib/kernel/validate.mli b/lib/kernel/validate.mli
index 5e55fc5..b46ca30 100644
--- a/lib/kernel/validate.mli
+++ b/lib/kernel/validate.mli
@@ -59,14 +59,24 @@ val failure_to_string : failure -> string
       fixed point.
     - ["admission"]: the rite's own [rules.admit] is a fixed point on what it
       already admitted -- re-offering a day's [commemorations] back to
-      [admit] (reconstructed with {!Precedence.Sanctoral} origin; the real EF
-      admit reads only rank and slug, never origin, so this reconstruction is
-      exact for it) must return exactly that same set. A cap-enforcing
-      selector that is not idempotent on its own output has, by definition,
-      admitted something its own rule would not admit if asked again -- the
-      rite-agnostic form of "the admission limit was not exceeded" available
-      without embedding a rite's specific numeric caps (RG 111's, for EF)
-      into kernel code.
+      [admit] (with [observed]'s own origin reconstructed as
+      {!Precedence.Sanctoral}; the real EF admit reads only rank and slug
+      from [observed], never origin, so this reconstruction is exact for
+      it) must return exactly that same set. Each offered commemoration's
+      own origin -- CORRECTED, Task B fix round 1 -- is recovered by
+      comparing its slug against the day's own temporal office, not
+      reconstructed as [Sanctoral] uniformly: {!Precedence.rules.admit}
+      (since Task B) is handed each candidate's own {!Precedence.rules.band}
+      value, computed here exactly as {!Precedence.resolve} computes it, and
+      [band] DOES read a candidate's origin (temporal- vs sanctoral-keyed
+      branches) even though EF's own [admit] itself still does not -- a
+      mislabelled origin would silently score the wrong table entry for a
+      genuinely temporal-origin commemoration (e.g. a Lent feria) before
+      this fix. A cap-enforcing selector that is not idempotent on its own
+      output has, by definition, admitted something its own rule would not
+      admit if asked again -- the rite-agnostic form of "the admission limit
+      was not exceeded" available without embedding a rite's specific
+      numeric caps (RG 111's, for EF) into kernel code.
 
     Total over the whole 1583..9999 domain, including [year] = 9999: the
     liturgical year opening there continues into out-of-domain civil year