Story: Currency pair support in reference data

ORE Studio treats currencies as first-class reference data, but currency pairs (conventions, quoting, cross rates) are not yet modelled as such. This story is the umbrella for the full currency pair feature: knowledge-base foundation (done), domain model design (done), the ores.codegen.entity implementation of that model, and librarian support so a new party gets a usable set of currency pairs out of the box. It stays open across all of that — it is not a design-only story.

• [X] A currency pair knowledge document set exists under doc/knowledge/, broken into small self-contained documents (conventions, quoting, cross rates, etc.) rather than one monolith.
• [X] The knowledge documents are cross-linked via org-roam [[id:...]] links, including to existing relevant documents (e.g. the cross rates matrix).
• [X] An index document ties the set together for discoverability.
• [X] The currency pair entity (and supporting currency fields) is modelled with all fields identified in the knowledge cluster, ready to drive ores.codegen.
• [X] Creating a party (via librarian) results in a usable set of currency pairs being available for it, following the same publish-from-dq pattern used by the synthetic FX foundation.

• Knowledge-base foundation shipped as six zettels plus a hub note, extending the existing CRM cluster rather than duplicating it (see the first task's * Plan).
• Currency pair modelled as its own entity (currency_pair), not folded into currency: spot_days and calendars are derived at read time from the two constituent currencies rather than stored redundantly on the pair, to avoid the two copies drifting apart. Five new columns land on currency itself (spot_days, deliverable, day_basis, base_precedence, holiday_calendar); a new currency_pair_classification auxiliary type reuses the existing rounding_type=/=monetary_nature=/=market_tier soft-FK pattern. Full field-by-field design lives in the second task's * Plan; three open questions (calendar/day-count representation, aux-type model type, fixing-source reference) are deferred to the implementation task.
• Corrected (third task): the initial design put G11 membership on the pair as a boolean is_g11 flag. That's wrong — it's a currency-level property, and desks need overlapping groupings beyond G11 (Scandies, Antipodeans, commodity currencies, …) that a boolean can't express. Replaced with a currency_group auxiliary type plus a many-to-many currency_currency_group_junction, mirroring the existing party_currencies junction pattern. currency.market_tier is unaffected and coexists as the single-valued primary tier alongside the new multi-valued group system.
• Discovered: ores.refdata.fx_convention already exists, fully implemented, and covers most of currency_pair's ground (spot days, a points_factor reciprocal to our pip_factor, a calendar field, business day convention, spot-relative/end-of-month flags). It exists only to round-trip ORE's conventions.xml <FX> element — no other consumer. Decision: retire it in favour of currency_pair, folding in its extra fields (see the reconciliation task).
• Split off (calendar): holiday_calendar (on currency) and advance_calendar (folded in from fx_convention, on currency_pair) are both unvalidated free text pointing at an ORE/QuantLib calendar name. Rather than keep them as raw strings, calendar modelling (validated calendar codes, FK relationships, Qt screens) is split off into its own backlog story, Model calendars as proper ORE Studio reference data — currency_pair keeps a raw-text calendar field only as an interim measure until that story lands and it can be migrated onto a real FK.
• Split into two entities: currency_pair (identity) and currency_pair_convention (1:1, the fx_convention-derived quoting/ date fields), matching the codebase's existing *_convention entity family rather than bundling both concerns into one entity. See the fourth task's * Plan for the finalized field lists.
• Split off (cut code): default_cut_code has no domain model anywhere in ORE Studio — same free-text-pointing-at-nothing problem as calendars. Split off into its own backlog story, Model market data cuts as proper ORE Studio reference data. Unlike the calendar field, default_cut_code is dropped from currency_pair entirely rather than kept as interim text — no current consumer needs it, so there's nothing to regress by adding it back as a proper FK once that story lands.
• Retired fx_convention: ores.ore, the Qt refdata plugin, and the CLI now read/write currency_pair=/=currency_pair_convention directly; all of fx_convention's SQL/C++/Qt/messaging files are deleted, not deprecated. SpotDays round-trips through a mapper-internal transport struct rather than a persisted field, since the file-based ore roundtrip import/export path has no database access and can't derive it from currency at that point. Two gaps left by earlier tasks were closed as a prerequisite: currency_pair's SQL was generated but never wired into the master schema/RLS scripts, and currency.spot_days was modelled but never regenerated — both fixed with C++/SQL-only changes to avoid clashing with the concurrent "Commission: currency" story.

• The day-count and fixing-source reference entities flagged as open questions in the second task.
• Proper calendar modelling — split off to Model calendars as proper ORE Studio reference data.
• Proper cut modelling — split off to Model market data cuts as proper ORE Studio reference data.