Story: Hotfix: refdata generator/repository test fixtures out of sync with DB constraints

Get CI green again: 25 failing ores.refdata unit/repository tests on main, caused by two "Commission: counterparty" codegen-facet commits (5ef46554b, d5762d746) that introduced generator values violating DB check constraints and diverging from existing test expectations.

• All previously-failing ores.refdata generator and repository tests pass.
• Root cause identified and documented per symptom cluster.
• No new magic-string change-reason literals introduced; existing ones touched by the fix migrated to the shared constants header.

• Root cause: commit 5ef46554b ("Populate counterparty codegen facets…") changed counterparty_generator.cpp's business_center_code from \"WRLD\" (the only seeded business centre) to the invalid \"USNY\", and change_reason_code from \"system.new\" to \"system.test\", without updating the tests that asserted the old values. Commit d5762d746 ("Close remaining counterparty gaps…") introduced an invalid \"LEI-{idx}\" numeric-suffix pattern for id_scheme in party_identifier_generator.cpp and counterparty_identifier_generator.cpp (DB only accepts 10 fixed scheme codes, not a per-record suffix).
• Fix: reverted business_center_code to \"WRLD\" (in both the .cpp and its .org codegen source), id_scheme to plain \"LEI\", and change_reason_code back to matching the sibling party_generator.cpp convention.
• Introduced codes::synthetic_new and codes::synthetic_test_data in the existing shared ores.dq.api/domain/change_reason_constants.hpp and migrated the 3 touched generators onto them, instead of leaving magic string literals in place — the class of bug that caused this drift in the first place. Wired ores.dq.api.lib as a new PRIVATE link dependency of ores.refdata.api.lib to make the header available.
• Filed a backlog capture (capture) to migrate the remaining ~30 ores.refdata generators onto the same constants — out of scope for this hotfix.
• CI failed again after the above landed, with a different root cause: generate_synthetic_counterparty_identifier=/ =generate_synthetic_party_identifier hardcoded id_scheme = "LEI" for every generated instance; LEI carries max_cardinality = 1 in refdata_party_id_schemes_populate.sql, so any batch of 2+ identifiers generated for the same party/counterparty deterministically violated the DB's cardinality trigger (write_multiple_counterparty_identifiers=/ =write_multiple_party_identifiers). Fixed by cycling through all id_scheme codes instead, centralised in a new shared ores.refdata.api/domain/party_id_scheme_constants.hpp (mirroring ores.dq's change_reason_constants.hpp pattern) and reused by party_id_scheme_generator.cpp, which had its own duplicate, unshared list. Verified locally: ores.refdata.core.tests passes 100%.
• Also landed on this PR, independent of the refdata fix: a TimescaleDB troubleshooting recipe (How do I fix a TimescaleDB "could not access file" error after an apt upgrade?) — needed locally to even run the tests after a host apt dist-upgrade bumped the timescaledb package — and a canary CI change (canary-linux.yml: debug build with code_coverage=1 → release build with no coverage), to cut PR turnaround time; canary's coverage data duplicated what continuous-linux.yml=/ =nightly-linux.yml already collect on the same matrix leg.

• Migrating all remaining ores.refdata generators to the shared change-reason constants (captured separately).