fix(18-07): money accepts trailing zeros beyond the field scale

A scale-2 money field over a four-decimal column (the documented fee
example) was served "12.5000" and answered money.too_precise when the
untouched value was saved back. Trailing zeros carry no precision, so the
server check and the SPA parser count only significant fraction digits;
the value still reaches the column unchanged, never rounded or truncated.

- cabana validateMoneyValue and admin parseMoneyInput trim trailing zeros
  before the scale comparison
- forms docs and cabana README name the rule; embedded dist rebuilt
- MoneyField spec asserts 12.5000 at scale 2 is accepted, 12.5010 refused

docs/backend/forms.md

@@ -499,7 +499,7 @@ A save checks every submitted money value before the transaction and answers a 4
 | Value | Answer |
 |-------|--------|
 | Not a string, or a string that is not an optional minus, digits and at most one dot followed by digits (`"1,5"`, `"1e3"`, `"1 000"`, a JSON number) | `money.invalid` |
-| More fraction digits than `scale` (`"12.34567"` at scale 4) | `money.too_precise`, with `:scale` |
+| More significant fraction digits than `scale` (`"12.34567"` at scale 4); trailing zeros do not count, so a scale-2 field over a `numeric(10,4)` column accepts its loaded `"12.5000"` | `money.too_precise`, with `:scale` |
 | Above `max` in absolute magnitude, compared as scaled digit strings | `money.too_large`, with `:max` |
 
 `null` is accepted and stored as NULL (or the column type's empty value); `required: true` refuses it through the usual rule. A value the administrator did not edit is sent back as it was loaded, so opening and saving a form with a stored `85.4193` writes `85.4193` again, never `85.42`. The same checks run on settings forms and relation forms.