Synthetic FX generation should respect currency pair conventions

ores.refdata already stores real quoting conventions per currency pair — currency_pair_convention.pip_factor, tick_size, decimal_places, calendars, business day convention — but ores.synthetic (confirmed by grep: zero references to tick_size=/ =pip_factor=/=decimal_places anywhere in the component) generates FX spot ticks purely from its GMM/OU process parameters, with no rounding or tick-snapping applied against the pair's own convention. A generated EUR/USD tick could legitimately land on a price no real EUR/USD quote could ever take (wrong decimal precision, off-tick), and there's no check that it's even the right order of magnitude for the pair's convention (a JPY cross with 2 decimal places vs. a major with 4-5, say).

Once synthetic feeds are meant to look/behave like real market data (the Realistic collection, Synthetic data collections: Basic and Realistic) — or once the future Cross-Rates Matrix or any consumer starts treating synthetic ticks as if they were real quotes — silently non-compliant precision/tick-size undermines that. The convention data already exists and is already published (refdata.currency_pairs=/ =currency_pair_conventions Librarian datasets); the gap is purely that the generator never reads it.

• projects/ores.refdata/api/include/ores.refdata.api/domain/currency_pair_convention.hpp — pip_factor, tick_size, decimal_places fields.
• projects/ores.synthetic/ — the generator with no reference to any of the above.

• Synthetic data collections: Basic and Realistic — the Realistic collection this would matter most for.
• Synthetic market data generation: approach — generation design.