[mstijak]

Fixes #1342. Alternative to #1343.

Problem

With culture-sensitive formatting enabled, formatters, compiled expressions and compiled templates are cached on the default culture, and each holds the NumberCulture / DateTimeCulture it was built with. setDefaultTimezone, setDefaultCurrency, setNumberCulture and setDateTimeCulture dropped at most the culture object, so formats used before the call kept the previous settings, even in widgets created after the call. Only setCulture reset the whole cache.

Dropping just dateTimeCulture and formatCache, as suggested in the issue, is not enough: compiled templates such as {date:datetime} capture their formatter and are cached on the culture too.

Fix

A module-level updateDefaultCulture(changes) applies the changes, resets the default culture's cache and calls Culture.invalidateCache(). All setters use it, including setCulture and setDefaultDateEncoding. invalidateCache() itself is unchanged.

Content rendered after a setter call uses the new settings. Widgets that already exist are not updated, same as with setCulture before.

Docs

concepts/localization.mdx:

• the setters apply to content rendered after the call; re-render after changing settings at runtime
• new Culture Scopes section: a detached Restate with createCulture(...) for content that needs a different culture, timezone or currency, and how to switch it with a ContentResolver

Tests

• Culture.spec.ts: setDefaultTimezone after first use (12:00 → 21:00); every setter leaves the default culture's cache empty. Both fail without the fix.
• Restate.spec.tsx: detached Restates render in their own culture.
• Checked separately with culture-sensitive formatting enabled: Format.value and a compiled {d:datetime;HHmmN} template both follow setDefaultTimezone (not in the suite, because culture-sensitive formatting can't be switched off).
• cx tests (579) and type check pass.