docs(rite-ef): correct a false band-value comparison in the RG16(a) comment

Fix round 1 review, MINOR finding (item 4). Both precedence_ef.ml and
test_precedence_ef.ml claimed the loser-side Class2 conjunct held because
'entry 6's own band value (6) is lower than every entry [3, 11-14]' --
false on its face (6 is not lower than 3) and, worse, the claim proves the
opposite of what it was cited for: if a band-3 candidate really did
contest a Class1 Sunday, the lower number would win, meaning the Sunday
would lose, not beat it as claimed.

The conclusion itself was never wrong, only the justification. Against
entries 11-14 (sanctoral-origin Lord feasts) the numeric argument holds
(6 < 11-14). Against entry 3 (Epiphany, Ascension, Trinity, Corpus
Christi, Sacred Heart, Christ the King) it is not numeric at all but
structural: every band-3 celebration is temporal-origin, and
Precedence.resolve takes exactly one temporal candidate per day, so a
band-3 Lord feast IS that date's own single temporal candidate, never a
second one contesting a separately-produced Sunday -- there is no band
comparison to make in the first place. Comment-only; no behaviour change.

2 files changed, 41 insertions, 10 deletions

diff --git a/lib/rites/rite_ef/precedence_ef.ml b/lib/rites/rite_ef/precedence_ef.ml
index 2987312..5688640 100644
--- a/lib/rites/rite_ef/precedence_ef.ml
+++ b/lib/rites/rite_ef/precedence_ef.ml
@@ -658,10 +658,31 @@ let disposition ~(winner : Vocab_ef.rank Precedence.candidate)
        (Advent/Lent/Passiontide, Low Sunday, {!band} entry 6) -- RG 16(a)'s
        own text says "Dominica II classis", not "any Sunday", and a I-class
        Sunday can never actually reach here as a [loser] against a
-       Class1-or-2 Lord winner in the first place: entry 6's own band value
-       (6) is lower than every entry a Lord feast of Class1 or Class2 could
-       occupy (3, 11-14), so a I-class Sunday always wins outright -- this
-       is exactly why the rubric restricts itself to II class. [is_sunday_slug]
+       Class1-or-2 Lord winner in the first place, for TWO DIFFERENT reasons
+       depending on the winner's shape (CORRECTED, fix round 1: the previous
+       version of this comment claimed "entry 6's own band value (6) is
+       lower than every entry [3, 11-14]" as a single numeric argument --
+       WRONG on its face, 6 is not lower than 3, and the claim would in any
+       case prove the opposite of what it was cited for: if a band-3
+       candidate really did contest a Class1 Sunday, the LOWER number (3)
+       would win, i.e. the Sunday would LOSE, not "always win outright" as
+       claimed):
+       - Against entries 11-14 (SANCTORAL-origin Lord feasts, e.g. the
+         Transfiguration): the numeric argument genuinely holds here --
+         entry 6 (6) IS lower than 11-14, so a I-class Sunday always wins
+         outright against these.
+       - Against entry 3 (TEMPORAL-origin Lord feasts -- Epiphany,
+         Ascension, Trinity, Corpus Christi, Sacred Heart, Christ the King):
+         not a numeric argument at all, but a STRUCTURAL one -- every
+         band-3 celebration is [is_temporal], and {!Precedence.resolve}
+         takes exactly ONE temporal candidate per day ([~temporal], not a
+         list), so a band-3 Lord feast IS that date's own single temporal
+         candidate, never a SEPARATE candidate contesting an
+         independently-produced Sunday on the same date. There is no
+         collision to resolve by band comparison in the first place.
+       Either way, no I-class Sunday can reach here as a loser against a
+       Class1-or-2 Lord winner -- this is exactly why the rubric restricts
+       itself to II class. [is_sunday_slug]
        (the same marker RG 33's [impedes_vigil] and RG 109(a)'s
        [privilege_of] already use, with no [is_temporal] guard there either
        -- no sanctoral slug this codebase's data produces contains
diff --git a/test/test_precedence_ef.ml b/test/test_precedence_ef.ml
index 52de989..8465870 100644
--- a/test/test_precedence_ef.ml
+++ b/test/test_precedence_ef.ml
@@ -587,12 +587,22 @@ let disposition_cases =
     (* Conjunct 2/4, LOSER rank: RG 16(a) names "Dominica II classis", not
        any Sunday. A I-class Sunday (Advent/Lent/Passiontide, Low Sunday,
        {!band} entry 6) can never actually reach here as a loser against a
-       Class1-or-2 Lord winner in real banding (entry 6's own band value, 6,
-       beats every entry such a winner could occupy, 3/11-14), which is
-       exactly why the primary text restricts itself to II class -- but
-       [disposition] takes no [context] and cannot itself re-derive that
-       band fact, so the rank check is what actually enforces it here.
-       Sourced from [Temporal_ef.temporal]'s own real output (Advent I
+       Class1-or-2 Lord winner in real banding -- CORRECTED (fix round 1):
+       not because "entry 6's own band value (6) beats every entry such a
+       winner could occupy, 3/11-14" (WRONG: 6 is not lower than 3, and the
+       claim proves the opposite of what it was cited for anyway -- see
+       precedence_ef.ml's own corrected comment on this same conjunct for
+       the full argument). Against entries 11-14 the numeric claim genuinely
+       holds (6 < 11-14); against entry 3 (Epiphany/Ascension/Trinity/
+       Corpus Christi/Sacred Heart/Christ the King) it is a STRUCTURAL fact
+       instead -- every band-3 celebration is temporal-origin, and
+       [Precedence.resolve] takes exactly one temporal candidate per day, so
+       a band-3 Lord feast IS that date's own single temporal candidate,
+       never a second one contesting a separately-produced Sunday. Either
+       way, this is exactly why the primary text restricts itself to II
+       class -- but [disposition] takes no [context] and cannot itself
+       re-derive that fact, so the rank check is what actually enforces it
+       here. Sourced from [Temporal_ef.temporal]'s own real output (Advent I
        Sunday 2026, Class1, "ef-advent-sunday-1"), the same row
        [disposition_cases]'s own RG95/RG109(a) entry above already uses.
        Dropping the [rank = Class2] conjunct on the loser would wrongly Omit