Generate webHtmlApp's strings, collapse a redundant string key

Strings.kt is now generated at build time (:webHtmlApp:generateStrings,
in webHtmlApp/build.gradle.kts) by parsing shared's strings.xml
directly, rather than a hand-maintained duplicate that could silently
drift from it. Names are mechanical camelCase of the XML key, so a few
call sites got more verbose (e.g. moveUp -> moveCurrencyUpContentDescription)
in exchange for zero manual sync. Only covers the base English locale.

Also collapses currency_option_label_local into currency_option_label:
the two had identical English text and existed only as a hook for a
future translation to phrase the user's own currency differently, which
no locale currently does. Removes the info.code == localeCurrencyCode
branching (and the now-pointless localeCurrencyCode parameter/field) from
all three UI implementations - PriceScreen.kt, CurrencyPickerSheet.swift,
and HtmlCurrencyPicker.kt - plus IosConverterState.localeCurrencyCode,
which existed solely to feed that branch on the Swift side.

Fixes a real regression surfaced while verifying the above by actually
building the Xcode project (not done since currencyFlagEmoji() gained
its supportsFlagEmoji parameter): Kotlin/Native doesn't generate
default-parameter overloads for Swift/ObjC-exported functions, so both
Swift call sites needed the argument passed explicitly, via the correct
exported facade name for an expect/actual pair - the actual file's
(SystemCurrencies_appleKt), not the common one (SystemCurrenciesKt).

Also drops "(DOM)" from webHtmlApp's page title.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

AGENTS.md

@@ -112,12 +112,18 @@ the pattern to copy: it returns a locale-formatted `String?` (using
 locale-aware formatting via platform APIs, not translated text), and each
 UI layer wraps it with its own localized "Updated %1$s" string.
 
-`webHtmlApp` is the one UI layer that deliberately breaks this pattern: its
-`Strings.kt` hardcodes English rather than calling `stringResource()`,
-because moko-resources' Compose integration (`moko-resourcesCompose`) pulls
-in `compose.foundation`/`compose.ui` transitively - exactly the dependency
-`webHtmlApp` exists to avoid (see "Module layout" above). Not a template to
-follow elsewhere; a one-off tradeoff specific to that module.
+`webHtmlApp` is the one UI layer that deliberately breaks this pattern: it
+can't call `stringResource()` because moko-resources' Compose integration
+(`moko-resourcesCompose`) pulls in `compose.foundation`/`compose.ui`
+transitively - exactly the dependency `webHtmlApp` exists to avoid (see
+"Module layout" above). Its `Strings.kt` is instead **generated** at build
+time (`:webHtmlApp:generateStrings`, in `webHtmlApp/build.gradle.kts`) by
+parsing `shared/.../moko-resources/base/strings.xml` directly, so that file
+stays the single source of truth instead of a manually maintained,
+silently driftable duplicate - edit the XML, not the generated file. Only
+covers the base (English) locale, since it skips moko's per-locale
+resolution entirely. Not a template to follow elsewhere; a one-off
+tradeoff specific to that module.
 
 ## Locale-aware formatting