Model Trinity Sunday as a real feast, not just a cosmetic label

Trinity Sunday wasn't modeled at all: getDayLabel had a purely
cosmetic "Trinity Sunday" label overlay for the Sunday after
Pentecost, but resolveTemporalId just fell back to post-pentecost-01
(ordinary-sunday category), so any Duplex+ saint assigned that date
(e.g. the Queenship of the BVM, fixed May 31) won outright, real
Trinity Sunday content never appearing anywhere.

Added a real temporal-feasts/trinity-sunday.yml record (Easter+56,
Duplex II. classis, live-verified). Per direct instruction,
unconditional: true (same shape as christ-the-king.yml) -- a
principal Sunday shouldn't lose a same-rank fixed-date collision, and
the one real collision case (Queenship of the BVM) isn't
independently verifiable against Monastic 1617 at all (that calendar
doesn't carry the Queenship feast -- May 31 there is St. Petronilla
instead).

Authored the full office and registered trinity-sunday in
ALWAYS_OVERRIDE_TEMPORAL_IDS -- the same generic mechanism already
built for the Pentecost-cluster fix, no new code needed: collect,
Benedictus/Magnificat antiphons, Matins hymn ("Summæ Deus cleméntiæ"),
Lauds/Vespers chapter (shared, Rom 11:33) and hymn (shared, "O lux
beáta Trínitas", already the pre-Urban VIII text), each hour's own
distinct responsory/versicle -- all live-verified 2026-05-31.

Fixed 3 pre-existing tests written around the old cosmetic-label
behavior, two of which had never-verified guesses baked in as if
correct: day-label.test.ts's "names the anchor day itself" test and
its "outranks an active octave" test (was asserting "Duplex I Class",
a guess -- the real live-verified rank is Duplex II);
transfer.test.ts's St. Felix I test.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AGjUyhUZJaSjiniEmnLdak

src/data/calendar/temporal-feasts/trinity-sunday.yml

@@ -0,0 +1,31 @@
+# Read from the reference engine: web/www/horas/Latin/Tempora/Pent01-0.txt
+# ("In Festo Sanctissimæ Trinitatis"), Duplex II. classis — live-verified
+# 2026-05-31 (Trinity Sunday itself that year). Previously not modeled as
+# its own record at all: `resolveTemporalId` just fell back to
+# `post-pentecost-01`, so this Sunday — one of the principal Sundays of
+# the whole year — displayed as a generic ordinary post-Pentecost Sunday,
+# with whatever saint happened to be assigned that date (if any) winning
+# outright per the plain `ordinary-sunday` rule. Found and fixed 2026-09-04
+# after the user asked about a display-only-looking gap that turned out to
+# be this much bigger mechanism gap.
+id: trinity-sunday
+name: "The Most Holy Trinity"
+# Reference engine's own [Officium] title is a prepositional phrase ("In
+# Festo Sanctissimæ Trinitatis"); adapted to this app's nominative-noun-
+# phrase convention.
+nameLa: "Sanctissima Trinitas"
+rank: duplex-2-classis
+anchor:
+  kind: easter
+  offset: 56
+# Per direct instruction (2026-09-04): always wins, same as christ-the-
+# king.yml's own `unconditional: true` — one of the year's principal
+# Sundays shouldn't lose to a same-rank fixed-date collision. The one
+# real case this matters for: the Queenship of the BVM (1954 addition,
+# fixed May 31, also Duplex II. classis) lands on the same date as
+# Trinity Sunday in rare years (e.g. 2026) — not verifiable against the
+# Monastic Tridentinum 1617 track directly, since that calendar doesn't
+# carry the Queenship feast at all (confirmed live: May 31 1617-track
+# shows St. Petronilla instead, this app's own blended-calendar-only
+# collision).
+unconditional: true