Bulk-regenerate synthetic generators to fix hardcoded r.version = 1

cpp_domain_type_generator.cpp.mustache (and its .org source, ores.cpp.generator.generator_impl.org) hardcoded r.version = 1; for every entity with audit columns. The DB insert trigger treats version = 0 as "no check, always allow and assign the next version", but a non-zero version is checked against the row's current version for optimistic concurrency — so a synthetic generator that always emits 1 makes any flow writing the same entity a third time fail with a spurious Version conflict: expected version 1, but current version is 2. Confirmed present as of 2026-07-07 in 36 generated files across ores.refdata (currency, currency_pair, party, country, book, and more — run grep -rl "r.version = 1" projects/*/api/src/generators/ to enumerate). The template was already fixed to emit version = 0 while investigating a build break in Migrate fx_convention consumers to currency_pair and retire it, and currency_generator.cpp was regenerated to pick up the fix (it was the one causing that PR's canary failure), but the other 35 files still carry the bug and need a bulk regen — check each entity's generated output against its model for unrelated drift first, the same way that task found and preserved a hand-patched faker::finance::currencySymbol() empty-string guard that a blind regen would otherwise have silently dropped.

Any future test or shell/CLI flow that writes a synthetic instance of one of the 35 affected entities more than twice will fail unpredictably with a "Version conflict" error that has nothing to do with the code under test — wasted debugging time, and a real risk of someone mistaking it for test flakiness and adding a retry instead of fixing the root cause.

• projects/ores.codegen/library/templates/cpp_domain_type_generator.cpp.mustache
• projects/ores.codegen/library/templates/ores.cpp.generator.generator_impl.org

• Migrate fx_convention consumers to currency_pair and retire it — where this was discovered and the template was fixed.
• Optimistic Concurrency Versioning: the version=0 Overload and Why It's a Problem — this bug (hardcoding 1 instead of 0) is a second, independent way to get the same undocumented sentinel wrong; that document is the definitive writeup of what version = 0 is actually supposed to mean.