Intl.DateTimeFormat timeZone option behavior during DST transition gaps

When using the Intl.DateTimeFormat API with a specific IANA time zone identifier, TypeScript relies on the underlying engine's ICU data to resolve localized strings. While the Date object only stores a UTC epoch, the conversion to a localized wall-clock string encounters specific challenges during Daylight Saving Time (DST) transitions.

The uncertainty arises when mapping a local time that is either non-existent (during a 'spring forward' gap) or ambiguous (during a 'fall back' overlap). Since the standard Intl methods do not provide an explicit configuration flag to resolve these edge cases manually, the resulting string depends on the implementation-specific logic of the JavaScript environment (Node.js or browser engine).

How does Intl.DateTimeFormat resolve a local time that does not exist due to a forward DST jump? Is there a native method within the Intl object to detect if a formatted date was adjusted without manual offset calculation?