Dissolve ores.qt.party plugin; migrate its entities into ores.qt.refdata

Migrate each remaining ores.qt.party entity into ores.qt.refdata, following the pattern established for party_type (see Commission: party_type story): regenerate the entity's Qt profile (codegen already places it under projects/ores.qt/{component}, i.e. refdata, with no knob or override needed — the plugin/component split was purely accidental drift, not an intended design), delete the old ores.qt/party copy, move its controller instantiation from PartyPlugin to RefdataPlugin, and add its menu entry to the shared organisation_codes_menu (shared_menus_context::organisation_codes_menu, introduced for this migration — host-owned in MainWindow.cpp, so RefdataPlugin and PartyPlugin can both contribute to the same physical submenu without a cross-plugin library dependency).

Remaining entities to migrate: party_status, party_id_scheme, contact_type, party, counterparty, business_centre, business_unit, business_unit_type. Once the last one migrates, PartyPlugin=/=ores.qt.party can be deleted entirely (empty on_login=/=setup_menus=/=on_logout, per the LegacyPlugin-shrinks pattern in the Qt plugin architecture analysis doc).

Investigating why party_type's NATS eventing never fired surfaced that its Qt code existed as two full duplicates — one hand-written in ores.qt/party (wired up, but with an empty event name so it silently never subscribed to anything) and one correctly codegen-generated in ores.qt/refdata (never actually compiled into the running plugin). Digging into why led to the real finding: every single entity currently in ores.qt.party has backend component=refdata (there is no ores.party C++ component at all) — the plugin is a UI-only grouping invented by hand, with zero corresponding backend structure. Per the project's stated preference (avoid accidental complexity; plugins should match components unless there's a strong reason otherwise), this mismatch is itself the architectural flaw that let the party_type duplication happen unnoticed. Migrating entity-by-entity as each is (re-)commissioned — rather than one big-bang move — keeps risk low and ties the work to work already being done on each entity.

• Commission: party_type — where party_type's migration happened first
• doc/analysis/qt-plugin-architecture.org — plugin/component layer diagram and migration-path precedent (LegacyPlugin shrinks to nothing)
• projects/ores.qt/api/include/ores.qt/IPlugin.hpp — shared_menus_context::organisation_codes_menu
• projects/ores.qt/application/src/MainWindow.cpp — host-owned menu creation

• Codegen gap: service application.cpp eventing pipeline not generated for new entities — the eventing-registration half of the same investigation