Task: Reconcile currency's flag image handling and wire the piloted combo-field mechanism

DetailDialogBase already has a complete, mature flag mechanism (initFlagButton, entityImageId()=/=keyFlagField()=/=keyFlagIcon() virtual accessors, onSelectFlagClicked, updateFlagDisplay, flagChanged()=/=selectedImageId()=/=resetFlagChanged()) — confirmed by CountryDetailDialog already using it end to end. Currency's ~180 lines of hand-rolled equivalent (flagButton_, pendingImageId_, flagChanged_, onCurrencyImageSet, manual updateFlagDisplay) were 100% redundant duplication, migrated to match Country's pattern exactly:

• initFlagButton(ui_->iconGroup->layout()) replaces the hand-built flag button/container.
• entityImageId()=/=keyFlagField()=/=keyFlagIcon() overrides added (matching Country's).
• getCurrency() now uses flagChanged()=/=selectedImageId() instead of the local pendingImageId_ staging.
• Dropped currency's extra onCurrencyImageSet NATS-confirmation toast handling — Country doesn't have this either; the generic imagesLoaded=/=allLoaded → updateFlagDisplay wiring (already in base's setImageCache) covers the refresh.
• Also dropped the "no-flag placeholder ID" auto-seeding quirk in the old setCurrency — unique to currency, inconsistent with how every other flag-icon entity handles a null image_id.

Landed a new combo_domain_type-gated branch in the detail_dialog template (cpp_qt_detail_dialog.cpp.mustache) generating a populateDynamicCombo<Entity> call from per-field org properties (combo_domain_type, combo_fetch_fn, combo_watcher_name, combo_code_field, combo_tooltip_field, combo_sort_field, combo_label, combo_setter_pascal) — distinct from the pre-existing (unused) combo_helper=/=combo_fetch_fn branches, which don't match the piloted helper's real 9-argument signature. Added currency's 3 combo fields (rounding_type, monetary_nature, market_tier) to a new "Detail fields" org table section (only these 3 — the other 11 currency fields stay unmodelled until the final sync task populates the full table).

Process note: initially hand-typed the on_error callback addition directly into CurrencyDetailDialog.cpp before adding the template capability — caught mid-edit (thanks to a review prompt) and reverted. Correct order followed after: land the template capability first, regenerate + diff to verify the generated populate*Combo() bodies match currency's real code, then copy the verified generated snippet in (adjusting only the real file's currentCurrency_ member name vs. the model's generic item_var naming — a pre-existing, unrelated drift).

The pilot (task 8AA363F8) flagged that populateDynamicCombo's bare std::vector<Entity> fetch signature can't distinguish "fetch failed" from "legitimately empty" — both render a silently-empty combo. Decision: land the fix, not just document a deferral. Changed populateDynamicCombo's fetch parameter to std::function<std::expected<std::vector<Entity>, QString>(ClientManager*)> and added an on_error callback (default no-op) plus a distinct "Failed to load" combo placeholder. Updated the 3 LookupFetcher functions currency uses (confirmed sole callers) to return std::expected, propagating process_authenticated_request's existing error channel instead of silently swallowing it. Currency's 3 combo call sites (both hand and generated) now pass an on_error callback that emits errorMessage().

Scoped to just the 3 functions currency uses — did not touch the rest of LookupFetcher's many other bare-vector fetchers (out of scope, no other entity affected).