feat(profile): persist a player's display decimal places

[damianrzepka]

Summary

BF-629. Adds a per-player display decimal places preference to the profile module: a nullable player.display_decimal_places (0-18, enforced by a database CHECK), returned as decimalPlaces on GET/PUT /profile/display-currency and set through the new PUT /profile/display-decimal-places ({ decimalPlaces: number | null }, null clears the pick). React: useSetDisplayDecimalPlaces from @openora/core/pam/react, which invalidates useDisplayCurrency.

Why

A consumer's "wallet decimal places" preference had no backing field, so it had no effect and did not survive a reload. The preference now lives on the account next to displayCurrency, so it follows the player across devices and ships in the display-currency read the balance header already loads, with no extra request.

The write and its audit record (player.display_decimal_places.set, before/after) commit in one transaction with the player row locked before the previous value is read, so two racing picks each audit the value they actually replaced.

Alternatives considered

• Browser storage in the consumer: no core change, but the setting would not follow the account, while the display currency on the same screen does.
• A dedicated read endpoint: rejected in favour of an additive field on the existing display-currency response.
• Restricting core to a fixed option set (e.g. 2/4/6/8): core stays headless and accepts 0-18 (the platform money scale); the UI decides which options to offer.

Risks

• Additive contract change: decimalPlaces is a new field on DisplayCurrencyInfo; existing readers are unaffected. A consumer that builds DisplayCurrencyInfo literals (fixtures, mocks) needs to add decimalPlaces: null to typecheck.
• Migration 0006 adds a nullable column and a CHECK constraint; existing rows stay NULL and satisfy it.
• Presentation only: the value must never be used to round a stored or submitted amount. Stated in the schema comment and the changeset.

🤖 Generated with Claude Code