Fixes#23828
## Problem
Opening and closing a currency field editor corrupts the stored amount
when the value has more decimals than the field's `decimals` setting
(which defaults to 0). No keystroke is needed.
- With the `1.234,56` number format, `458.64` is persisted back as
`45864`.
- With the `1,234.56` number format, `458.64` is persisted back as
`458`.
## Root cause
The draft amount is serialized with a dot decimal separator
(`amountMicros / 1000000).toString()`), and `CurrencyInput` hands that
string to the IMask `Number` mask with `scale={decimals}` alongside the
workspace `thousandsSeparator` and `radix`. With `scale` 0 and a dot
thousands separator, imask reads `458.64` as `45864`; with a dot radix
it drops the fraction and yields `458`.
That misreading is only half of it. `react-imask` re-emits `accept`
while it formats the value it was given, so **merely mounting the
editor** pushed the mask's own reading of the amount into `internalText`
and into the draft value. From there every exit path persisted it,
escape included. That is why the corruption needs no keystroke.
## Fix
Two layers, smallest first:
1. `CurrencyInput` ignores `accept` events that carry no originating
input event. In imask, `_inputEvent` is set only inside `_onInput` and
deleted right after, so a user keystroke (including the reformat emitted
within the same turn) always carries it, while mount and programmatic
updates never do. The draft can now only change because someone typed.
2. The exit handlers pass `skipPersist` when the resulting value already
matches the stored one, so opening and closing a field writes nothing at
all - no redundant update, no timeline entry.
`getSafeScaleForCurrencyInput` is kept as well: the mask scale is what
makes the editor *display and edit* the right number. Without it, a
`458.64` amount still opens as `45.864`, and a genuine edit would then
build on the wrong base and persist legitimately.
## Tests
Unit tests on both utils, plus an imask round-trip of `458.64` with
`decimals` 0 across all four number formats, which fails on `main` for
both dot-separator formats.
Verified in a local instance against the reported case (`458.64`,
`decimals` 0):
| scenario | result |
|---|---|
| open + close, `1.234,56` | value unchanged, `updatedAt` untouched (no
write at all) |
| open + close, `1,234.56` | value unchanged |
| type a new amount | persists normally |
| type `12.5` on a `decimals` 0 field | yields `125`, separator still
rejected |
Thomas Trompette
00b6d651f4