gen-sanctoral-ef, caldata: fix round 3 -- guard coverage, rank pins, name test, Anastasia

Second external re-review returned Spec pass on round 2 (all ten prior
findings addressed, C1/C2 fixed at the root, mechanism claims held
under mutation) and found two blocking items in the I3 guard itself,
plus three recommended hardenings. All verified independently before
fixing.

BLOCKING 1: refYearExplainsAbsence's own doc comment said the id-rank
exclusion covers "6-31 December"; the code implemented `Day() >= 26`.
A typo (26 -> 6), but the wrong kind to have on the one comment this
whole review chain exists to keep honest -- fixed as part of the
rewrite below, not left as an isolated one-character correction.

BLOCKING 2: the guard covered only 6 of the 13 MM-DD values round 1's
own temporal_ef.go changes actually made refYearExplainsAbsence
couple to. Measured, not just reasoned about: running the function's
body against the branch-point engine versus HEAD over the six
reference years flips its verdict on 50 dates across 12-17 through
12-23 (round 1's late-Advent promotion, RG 91 entry 18, a 140-day
change) AND 12-26 through 12-31 (the Nativity-octave promotion, RG
67/68, already guarded). The late-Advent half was unguarded.

No live bug today -- confirmed by regenerating: the ini is
BYTE-IDENTICAL before and after this fix. The only sanctoral entry in
17-23 December is `thomas` (21 December), reached via harvestDate's
`obs` (observed-office) path, never refYearExplainsAbsence's
commemoration-id-trust path at all. Widened the guard to 17-31
December anyway, on the side of the known-safe default
(RankCommemoration) rather than wait for the first real entry in that
range to repeat I3's exact failure shape. The two sub-ranges are NOT
the same strength of evidence, and the doc comment says so explicitly
now: 26-31 December rests on a positive RG 68(d)/(e) citation naming
Thomas Becket and Silvester directly as bare "Commemoratio, no
class"; 17-23 December is a precautionary exclusion with no equivalent
citation -- RG 91 entry 18 ranks the FERIA, not any commemoration
that might coincide with it, and (per defect 2's own finding) a
genuine class-2 feast there would actually WIN against the ferias's
own privilege, so "the day is class-2" does not reliably explain a
class-2 saint's absence here the way it does for the Nativity octave's
two named cases. Recorded as a real asymmetry, not smoothed over.

RECOMMENDED 3: rank = commemoration is now pinned for all four entries
this task's two review rounds touched -- romanus, eusebius-confessor
(C2), thomas-becket, silvester (I3) -- not just their presence and
date. `git grep` before this commit returned zero hits for
thomas-becket or silvester rank anywhere in *_test.go; a future
regeneration could have rewritten either back to class-4, the exact
I3 failure mode, with the suite green throughout.

RECOMMENDED 4: TestTridentineNamesPreservedAcrossRegeneration
rewritten on both axes the review found loose. It counted name.pl
only -- a hardcoded single language, the identical "whitelist of two"
mistake C1's own generator fix exists to stop repeating, just moved
into the test instead. Now DISCOVERS every name.<lang> key actually
present in the data (so a regeneration dropping name.la, or losing a
future name.de, is caught the same way as name.pl) and asserts the
discovered language set is exactly {en, pl} -- not just each count.
The >= 315 floor had 7 entries of slack (the review proved 6 missing
Polish names still passed it); tightened to the exact, independently
verified true count (322), zero slack.

RECOMMENDED 5: the 25 December Anastasia gap and its cause are now
recorded, not just her absence. Two compounding, independently
checked causes: fetchOnce reads only `data[0]`, missalemeum's FIRST
of Christmas Day's three Masses, so a commemoration attached to a
second or third Mass (the calendarium's own "In secunda Missa:
Commemoratio S. Anastasiae Mart.") is structurally invisible to this
harvester for ANY date, not just this one -- but ALSO, checked live,
missalemeum's own "commemorations" list is empty on all three of the
date's records, not just the first, so a fetchOnce rewritten to merge
all of a date's Masses would still not recover her. Documented at
both fetchOnce's own definition and the PRIMARY-SOURCE NOTE, since
the two facts belong to different questions (a real code limitation
worth fixing someday vs. an upstream data gap this generator cannot
close at all).

Witnesses: TestTridentineCommemorationRanksPinned (new),
TestTridentineRomanusAndEusebiusPresent (extended with rank),
TestTridentineNamesPreservedAcrossRegeneration (rewritten). No pre-fix
failure to report for the two new/tightened tests specifically --
these are regression GUARDS against a bug class already fixed in
round 2, not fixes for a currently-red state; their value is in what
they would now catch, not what they catch today. internal/caldata/
tridentine-calendar.ini is NOT regenerated by this commit -- confirmed
byte-identical before and after re-running the generator, exactly as
"no live bug today" predicts.

0 files changed, 0 insertions, 0 deletions