fix(kernel): a transferred candidate can settle as a commemoration, not only as observed

Calendar.build_day's `unresolved` check decided whether a Transfer-disposed
candidate had genuinely settled at its target by checking only whether it
became that day's own `observed` celebration. That was correct for every
prior use of Precedence.Transfer: a losing FEAST, which RG-96-style rules
guarantee an unblocked target to win outright once it arrives.

It is not correct in general. A rite's rules are free to dispose a
Celebration.status = Commemoration_only candidate as Transfer too (the EF
Major Litanies, RG 80, do exactly this) -- and such a candidate can never
become `observed` anywhere, by the same status that makes it eligible to
transfer in the first place. The old check mislabelled a cleanly-settled
transfer of that shape as "did not converge" (a hardcoded string, not a
real read of the placement pass's own convergence) and double-counted it
in Validate's own duplicated-sighting check.

Replaced with `settled_at`, which re-resolves the target date and accepts
either `observed` or membership in that day's own admitted commemorations.
A strict superset of the old check -- every existing use (a transferred
feast winning its target) is unaffected -- and stays rite-agnostic: it
reads only Precedence.resolution's existing fields, no EF-specific
knowledge added to the kernel.

Found by the exhaustive property sweep (COLITUR_EXHAUSTIVE_SWEEP=1) the
moment a rite first produced this shape, not anticipated in advance.

0 files changed, 0 insertions, 0 deletions