Separate trade and instrument detail dialogs

Split the current combined trade-plus-instrument details dialog into two separate detail dialogs — one for the trade, one for the instrument — and work out how a user navigates from one to the other. The navigation mechanism is the open design question and deserves a brainstorm session on idiomatic patterns in trading systems before committing to a design. Candidate patterns to seed the brainstorm:

• A button/link in trade details that opens the linked instrument details (the simplest option).
• Hyperlinked entity references: any field that is a soft FK (instrument_id, book_id, portfolio_id, party_id) renders as a navigable link — the pattern generalises beyond trade/instrument.
• Master-detail drill-down: instrument opens as a nested tab or panel inside the trade window rather than a separate top-level window.
• Blotter-style navigation: trade blotter row → trade details → "View Instrument" action, with breadcrumbs to step back.
• A shared "related entities" sidebar listing all linked entities of the focused record (what OMS/EMS front-ends often do).

The combined dialog tries to display two distinct aggregates in one window, which crowds the UI and couples the dialogs' lifecycles. Now that instruments are first-class (own tables, own NATS messages, own forms per type — see the C1202 nested-structs work), a dedicated instrument details dialog is natural, and the trade dialog gets simpler. The trade→instrument soft FK (classification.instrument_id / identity.trade_id) already provides the navigation key in both directions.

• Story: Fix rfl complexity failure (Windows + macOS CI) — instrument decomposition that makes instruments first-class.

• Story: Consolidate history dialogs onto HistoryDialogBase — parallel effort to rationalise dialog architecture.