docs: close the final review's four documentation residues

precedence_ef.mli said "there is no fifth, unclassified case" after the
same commit renumbered the disposition list from four cases to five; the
count is now six.

precedence.mli's physical-equality obligation described the failure mode
as counting a drop "a SECOND time (once because it is genuinely absent,
once because its identity no longer matches)" -- the same condition
stated twice. What actually happens to a rebuilt candidate record is
that the celebration surfaces in BOTH commemorations (the copy) and
omitted (the original), one admission double-reported. precedence_ef.ml
carried the same muddled sentence, which is where the kernel's copy came
from; both now say it plainly.

vocab.ml/.mli referenced {!Rite_ef.rite_ef.ml} -- a filename inside an
odoc reference, which is malformed. Now plain [Rite_ef.rite].

README documented only `dune test`, so the exhaustive 1583-9999 Validate
sweep was discoverable only by reading test_validate.ml's own comment.
With no CI in this repo, that line is what stands between a committed
artifact and one anyone runs.

No behaviour change: `colitur day` output is byte-identical across 1583,
1900, 1902, 2008, 2011, 2026, 2038 and 9999 (2921 days, both domain
edges). 259 tests by default, 260 with the sweep.

1 files changed, 7 insertions, 5 deletions

diff --git a/lib/kernel/precedence.mli b/lib/kernel/precedence.mli
index 4225eb7..ae054dd 100644
--- a/lib/kernel/precedence.mli
+++ b/lib/kernel/precedence.mli
@@ -47,11 +47,13 @@ type ('s, 'r) rules = {
           {!resolve}'s own [omitted] accounting distinguishes an admitted
           candidate from a dropped one by PHYSICAL equality ([==]) on the
           candidate value, not structural equality -- a rebuilt record is
-          [=] to the original but not [==], so {!resolve} would then count
-          it as dropped a SECOND time (once because it is genuinely absent
-          from the admitted set, once because its identity no longer
-          matches its own admitted copy), silently double-counting rather
-          than raising. This obligation previously lived only in one rite's
+          [=] to the original but not [==], so {!resolve} cannot match the
+          rebuilt copy against the original it was given. The celebration
+          then surfaces TWICE in the same day's result -- once in
+          {!resolution.commemorations} (the rebuilt copy, admitted) and once
+          in {!resolution.omitted} (the original, which nothing in the
+          admitted set matches). One admission, double-reported, silently
+          rather than raising. This obligation previously lived only in one rite's
           own module documentation (Rite_ef.Precedence_ef.admit); stated
           here because this signature -- not any one rite's implementation
           of it -- is what an author of the next rite reads. *)