fix: place currency symbol correctly based on locale convention

[piotr-iohk]

Fixes #408

Description

This PR fixes currency symbol placement for currencies that display the symbol after the amount (PLN, CZK, SEK, CHF, NOK, DKK, HUF, and others). Mirrors the fix from bitkit-android#733.

1. Adds a suffixSymbolCurrencies set and isSuffixSymbolCurrency() helper as single source of truth for currencies whose symbol goes after the amount
2. Adds isSymbolSuffix property and formattedWithSymbol() method to ConvertedAmount
3. Updates MoneyText and NumberPadTextField to conditionally place the symbol before or after the amount
4. Replaces manual symbol concatenation in ReceiveCjitConfirmation, BoostSheet, and WeatherViewModel with formattedWithSymbol()
5. Adds 15 unit tests for the new formatting logic

Adding a new suffix currency only requires adding it to the suffixSymbolCurrencies set — all UI components derive behavior from it.

Linked Issues/Tasks

• Fixes Currency symbol displayed in wrong position for PLN, CZK, SEK and other currencies #408
• Related android PR: fix: place currency symbol correctly based on locale convention bitkit-android#771

Screenshot / Video

Screen.Recording.2026-02-09.at.14.12.49.mov

[ovitrif]

@piotr-iohk usually the Swift and Kotlin coding languages have built-in APIs for locale-based number formatting (and currency specific variants).

Did you already try to inquire with your AI agent if using those is not feasible here?!

You normally should get the "perfect" placement of currency symbol for all locales.

[piotr-iohk]

@piotr-iohk usually the Swift and Kotlin coding languages have built-in APIs for locale-based number formatting (and currency specific variants).

Did you already try to inquire with your AI agent if using those is not feasible here?!

You normally should get the "perfect" placement of currency symbol for all locales.

We did evaluate built-in locale/currency formatting APIs.
For this fix, we intentionally kept deterministic app formatting + explicit suffix rules.

Why:

1. Fiat formatting in the app is currently not fully locale-driven (we enforce separators/patterns), so changing only symbol placement was the safest minimal fix.
2. Currency.getInstance(...).getSymbol(...) is locale-dependent and can return codes instead of expected symbols in non-native locales, which is not always what we want for current UX.

Concrete example:

• Currency.getInstance("PLN").getSymbol() -> PLN (default en_US)
• Currency.getInstance("PLN").getSymbol(Locale.US) -> PLN
• Currency.getInstance("PLN").getSymbol(pl_PL) -> zł

Similarly:

• SEK with Locale.US -> SEK
• SEK with sv_SE -> kr

So for now we use API-provided symbol values and control placement explicitly for consistent display.
Of course, this can be reevaluated in the future.

[pwltr]

LGTM, left one small comment

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.