Story: Composite child-entity and hierarchy Qt widgets for codegen

Discovered while verifying counterparty's Qt UI (Commission: counterparty): party and counterparty share a hand-maintained EntityDetailDialog=/=EntityDetailOperations abstraction (~2,300 lines) implementing capabilities the current Qt codegen profile has no facet for at all — embedded, editable identifier and contact child tables, and a self-referencing parent-hierarchy tree view. Naively running --address ores.cpp.qt on these entities would regress functionality, not migrate it. This story adds the missing capabilities to codegen properly, so party and counterparty (and future org-hierarchy entities) can eventually retire the hand-maintained abstraction.

Sequenced in three tasks:

1. Design the child-entity Qt facet: counterparty_identifier, counterparty_contact_information, party_identifier, and party_contact_information are already full codegen entities with no * Qt facet of their own (they're not independently navigable). Determine whether an embeddable child-table widget, fetched via the foreign_keys=/=list_by paged backend query already added this sprint, is generatable as a facet — or whether it needs its own handcrafted base widget with a thin generated binding, mirroring the hierarchy approach below.
2. Build two 100%-handcrafted, reusable classes: a generic HierarchyTreeWidget (self-referencing id/parent-id/label tree, no entity knowledge), and a hierarchy-model-builder that, given a party or counterparty entity list, produces a tree model ready to hand to the widget. Add minimal paste-block seams to the Qt detail-dialog codegen templates so a generated dialog can construct the model builder and plug it into the widget with as little pasted code as possible.
3. Once 1 and 2 are proven, design and execute binding both against party and counterparty specifically, verify feature parity against the current hand-maintained dialog, and retire EntityDetailDialog=/=EntityDetailOperations once confirmed.

• Written design decision on whether identifier/contact child entities need a new codegen Qt facet, or a handcrafted base widget + generated binding, for embeddable child tables.
• HierarchyTreeWidget and its hierarchy-model-builder exist, 100% handcrafted, entity-agnostic, unit-testable independent of party=/=counterparty.
• Qt detail-dialog codegen templates (header/impl/ui) have paste-block extension points, following the existing repository/service :implements <UUID> convention.
• party and counterparty regenerate through the new facets with verified feature parity (identifiers, contacts, hierarchy) against the current hand-maintained dialog before the old code is removed.

Child-entity tables (identifiers, contacts) will use a handcrafted, reusable widget (EmbeddedChildTableWidget, parameterized by column defs + fetch/save/remove callbacks) plus a thin generated binding — not a new codegen Qt facet — mirroring the hierarchy-widget decision. Only two distinct column shapes exist across all 4 child entities (identifier shape, contact shape), and the backend paged fetch-by-parent-id query is already fully generated. See task 1's * Notes for the full evidence trail.