Task: Migrate party_status/party_id_scheme/business_unit/business_unit_type from ores.qt.party to ores.qt.refdata

party and counterparty themselves were already migrated from ores.qt.party to ores.qt.refdata earlier in this story (see Bring party under codegen and Regenerate counterparty under codegen), but ores.qt.party still hosts four related/lookup entities that were never moved: PartyStatus, PartyIdScheme, BusinessUnit, and BusinessUnitType. Migrate these to ores.qt.refdata for consistency, and regenerate each against the current codegen templates while doing so — the fact they were never moved strongly suggests they haven't been regenerated recently either and may carry the same kind of template drift party/counterparty had accumulated.

• party_status, party_id_scheme, business_unit, business_unit_type all confirmed living under ores.qt.refdata (component migration was already complete for all four).
• All four regenerate against current codegen templates with zero diff (business_unit required a new codegen seam first).
• business_unit's IBusinessUnitBrowser cross-component interface (consumed by ores.qt.trading's OrgExplorerMdiWindow) preserved through regeneration via a proper model property, not a hand-patch.

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

• Discovered while writing the party manual chapter: asked "what's left in ores.qt/party now" and found PartyStatus, PartyIdScheme, BusinessUnit, BusinessUnitType still living there.
• Check each of these four against current codegen templates with --diff before regenerating, the same way party/counterparty were checked, since they may carry unrelated hand-patches that need reconciling first.
• BusinessUnit=/=BusinessUnitType are not part of this story's party=/=counterparty=/=party_status scope as originally framed — confirm whether they belong here or should be split into their own story before starting.

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.

Confirmed all four entities (party_status, party_id_scheme, business_unit, business_unit_type) already live under ores.qt.refdata — ores.qt.party doesn't exist as a component any more, so that half of the task was already complete. Regen-against- current-templates was clean for three of the four; business_unit was not, because its hand-written IBusinessUnitBrowser implementation (consumed by ores.qt.trading's OrgExplorerMdiWindow for cross-plugin decoupling) had no corresponding model declaration and would have been silently deleted by a naive regen.

Extended codegen with a new qt.explorer_interface model property (companion to the existing has_explorer_api knob): when set, the generated Controller additionally implements the named interface (extra base class + override on openEdit=/=openHistory), letting business_unit regenerate cleanly while preserving the cross-plugin contract. Verified zero-diff on re-generation, and that all other has_explorer_api consumers (book, portfolio) and the three sibling lookups are unaffected by the codegen change.

Manually verified via a QA scenario against Org Explorer: edit and history both correctly open the right business unit through the interface. Found (and filed separately, not fixed here) four pre-existing, unrelated gaps while testing: Org Explorer's tree has no double-click handler, business unit has no badge emblems, its Business Centre field is plain text rather than the flagged combo party/counterparty use, and editing a business unit doesn't live- refresh an already-open Org Explorer.