feat(datetime-adapter,core): opt-in strictLocale mode for fail-fast locale handling

[droshev]

Context

PR #14016 introduced two new silent fallback paths (replacing pre-PR fail-fast / hardcoded behavior):

1. DayjsDatetimeAdapter.setLocale() (libs/datetime-adapter/src/lib/dayjs-datetime-adapter.ts)
   • Pre-PR: throw new Error('Failed to load locale ...') on unknown locale.
   • Post-PR: console.warn(...) then falls back to 'en'. Production users may never see the warning.
2. FdDatetimeAdapter.getFirstDayOfWeek() (libs/core/datetime/fd-datetime-adapter.ts)
   • Pre-PR: hardcoded return 0 (always Sunday).
   • Post-PR: tries Intl.Locale.weekInfo and silently catches errors back to 0. Older browsers without weekInfo mis-render the calendar's first column with no signal to the app.

The fail-soft default is correct for most apps — a typo in a locale string shouldn't crash an app. But apps that want fail-fast (CI pipelines, regulated environments, locale-coverage testing) currently can't opt in.

Proposal

Add a strictLocale: boolean option to provideDayjsDatetimeAdapter() (and the equivalent for FdDatetimeAdapter). When true, the fallbacks throw instead of warn / silently-correct.

// Default — current behavior preserved
provideDayjsDatetimeAdapter();

// Strict — throw on unknown locale or missing Intl.Locale.weekInfo
provideDayjsDatetimeAdapter({ strictLocale: true });

Acceptance criteria

• provideDayjsDatetimeAdapter({ strictLocale: true }) accepted
• Unknown locale → throws with a clear message naming the missing locale
• Missing Intl.Locale.weekInfo → throws with browser-feature error
• Default (strictLocale: false or unset) preserves current PR fix: datetime adapters migration #14016 behavior — no regression for existing apps
• Documented in the datetime-adapters README

Related

• fix: datetime adapters migration #14016 — datetime adapter migration that introduced the silent fallbacks