Task: Qt composite history/version dialog

Extend the party/counterparty History dialog with a "Composite (as of this version)" tab showing the identifiers and contact information that composed the entity as of a selected historical version, reaching all the way through NATS to the already-proven repository/service layer from the previous task.

• New NATS message pair (get_party_composite_as_of_request/response, get_counterparty_composite_as_of_request/response) reaches the already-proven repository/service as-of methods and returns the parent + its identifiers + its contacts as of a given version.
• PartyHistoryDialog=/=CounterpartyHistoryDialog gain a "Composite (as of this version)" tab, populated whenever a version row is selected, listing identifiers and contacts as they stood then.
• Builds cleanly end to end (refdata core lib, Qt party lib, full build, controller/refdata services, Qt client all rebuilt).
• Confirmed live in the running client (pending).

Added one hand-written composite NATS message per parent (not a generic per-child message) since the Qt dialog needs "parent + all its children as of a version" in one round trip, not separate calls per child type — the handler internally reuses the exact get_<entity>_at_version=/=list_<entity>_by_<fk>_as_of service calls proven in the previous task. Window end for the requested version is derived by fetching version+1 and using its recorded_at (windows are contiguous by construction); the current/latest version's still-open end is bounded with a safely-far-future instant, same approach as the proof test in the previous task.

Wired: protocol structs (party_protocol.hpp=/=counterparty_protocol.hpp), handler methods (party_handler::composite_as_of=/ =counterparty_handler::composite_as_of), registrar subscriptions, and the Qt side — a new tab in each history dialog's .ui, populated via the existing generic runHistoryRequest async helper (already used for loadHistory), triggered from displayFullDetails (already the hook point for "a version row was selected").

Did not attempt a raw live NATS round-trip test outside the Qt client (the handler requires JWT auth via make_request_context, and faking that from a shell/CLI script for a one-off check wasn't worth the detour) — instead relied on: (1) the underlying repository/service calls already being proven correct with real data in the previous task, (2) clean compilation of the handler/registrar wiring (which would fail to compile if the message types weren't properly reflectable or the service signatures didn't match), and (3) a full rebuild of every affected binary (refdata core lib, controller service, refdata service, Qt client) succeeding. Live visual confirmation in the running client is the remaining verification step (see * Test Scenarios below).

Manual QA scenarios (scaffolded via compass add test_scenario, run through the QA Validation Runner panel) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.