fix(rite-ef): band has no table entry for a bare commemoration, ever

Fix round 1 on the commemoration-identity/tie-break work: the "genuine
same-band tie" M17 adjudicated as open was not a tie at all. RG 91's
table enumerates only "dies liturgici" (real feasts) -- entry 24's own
text is "Festa III classis, in calendario Ecclesiae universae
inscripta" -- so a Celebration.t.status = Commemoration_only candidate
(a saint reduced to a bare commemoration) has no row in the table to
begin with. Precedence_ef.band used to read rank alone, so it silently
lent such a candidate the same table entry as a genuine Feast of its
own rank; the calendarium's own 22 September row confirms the
distinction in its own notation ("S. Thomae de Villanova ... III
classis. / Commemoratio Ss. Mauritii et Soc. Mm." -- Thomas carries a
class number, Maurice carries none).

Fixed at the source, not by adding a status tier to compare_precedence:
band now checks status first, ahead of every rank-keyed branch, and
returns unclassified for any Commemoration_only candidate. M17 deleted
(not re-adjudicated) -- 22 September now resolves identically on both
sides, with no divergence left to name.

Blast radius measured independently (a temporary git worktree at the
pre-fix commit): 4451 days change across the whole 1583-9999 domain,
exactly 4 verified shapes -- 3576 x maurice-and-companions-martyrs ->
thomas-of-villanova and 282 x eleutherius -> philip-neri (admitted set
changes), 502 x appollonia/cyril-of-alexandria and 91 x dorothy/titus
(order only, independently confirmed against the calendarium's own
listing convention). Zero days change who is observed. Further swept
the whole domain for a genuine "two different candidates on the
identical real table entry" residual -- the shape RG 113 truly gives
no instruction for -- and found it empty: of 109201 same-rank ties
domain-wide, 83950 now resolve by band alone and the remaining 25251
are exclusively two Commemoration_only candidates tied at unclassified,
never two real feasts. The residual admit still breaks alphabetically
is real, but narrower than previously documented.

The "66 days" figure is reconciled, not merely disputed: 599 is the
tie population, 65 (whole-comparator: 67) is the real admitted-set
decision count within it (independently reproduced against the
pre-Task-B binary), 149 is order-only. Every one of the 65 real
decisions traces to the same Commemoration_only/Feast root cause as
Maurice/Thomas.

Also: validate.ml's admission fixed-point check recovers a
commemoration's real origin (by matching its slug against the day's
own temporal office) instead of reconstructing every candidate as
Sanctoral, since band -- unlike EF's own admit -- does read origin;
precedence_ef.ml/.mli's motivating example and blast-radius claims
corrected to no longer rest on the fixed Maurice/Thomas case;
test_identity_rank_corroboration's own population count corrected now
that 22 September (and 21 other Feast-status matches) became reachable;
its rank-agreement pin documents exactly what it does and does not
prove. Register (§4, §6.1, §6 checklist) and CLAUDE.md corrected in
place, including the RG 113 first-sentence gap this exercise surfaced
but did not close, recorded as a new open item.

275 -> 276 tests (with the exhaustive sweep), all green.

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