Guarantee that a format returned from DateTimeStyleFormat can also be returned by BasicFormatMatcher/BestFitFormatMatcher

[ptomato]

See tc39/proposal-temporal#3062.

It seems that DateTimeStyleFormat may return a DateTime Format Record that BasicFormatMatcher and BestFitFormatMatcher cannot. @anba explains it pretty well in tc39/proposal-temporal#3062 (comment) — it seems that DateTimeStyleFormat's data source is %Intl.DateTimeFormat%.[[LocaleData]].[[<locale>]].[[styles]], while the format matchers' data source is %Intl.DateTimeFormat%.[[LocaleData]].[[<locale>]].[[formats]], and CLDR has inconsistencies between those data sources. (https://unicode-org.atlassian.net/browse/CLDR-14993)

This seems like an artificial limitation based on inconsistencies in CLDR. The spec should require consistency here, even if implementations using CLDR cannot deliver that yet.

How best to ensure this consistency in spec text, I'm not sure.

Possibly related: #189?

[sffc]

TG2 discussion: https://github.com/tc39/ecma402/blob/main/meetings/notes-2026-02-19.md#402-issue-1043

Conclusion for now: this doesn't seem motivated enough for ECMA-402 to take a strong stance for moving the needle. We will wait for CLDR to make a change, and then consider encoding the invariant in ECMA-402 once it has become web reality.