Task: Land setting-gated action-visibility knob as a qt-profile template capability

The mechanism (setupGenerateAction=/=updateGenerateActionVisibility=/ =onSystemSettingNotification) is duplicated near-verbatim in both CurrencyMdiWindow and CurrencyDetailDialog: subscribe to the system_setting_changed_event NATS event on login/reconnect, listen for ClientManager::notificationReceived, and on either a notification or an explicit refresh, run a QtConcurrent task issuing variability::messaging::list_settings_request and setting the action's visibility from the (single) matching setting's boolean value. ~50 lines duplicated per file, entirely generic apart from the setting name and which QAction* it gates.

Extract a reusable, non-templated helper — SettingGatedActionController (QObject, ores.qt/api, same "generalise the wiring, not the entity" shape as ImportEntityDialog) — rather than generating the ~50 lines per action in mustache:

• explicit SettingGatedActionController(ClientManager*, QObject* parent = nullptr) wires the login/reconnect/notification subscription once, internally.
• void registerAction(QAction* action, QString setting_name) — adds an action to gate; one controller instance can gate several actions off different settings, so a single NATS subscription and a single list_settings_request batch-check covers all of them (avoids N separate fetches for N gated actions).
• void refresh() — force a re-check of every registered action (called after login, and by the caller if already logged in at construction time).
• Internally: on a system_setting_changed_event notification, only re-checks if the changed setting name is one of the registered ones; on refresh(), one list_settings_request, then set every registered action's visibility from the matching setting.

Codegen side: a new "Setting-gated actions" Qt table section (one row per action: action field name, setting name — mirrors the shape of the existing "Icon columns (Qt model)" table rather than a single boolean flag, since the acceptance criterion is genericity over any action, potentially more than one per entity). has_setting_gated_actions is derived (non-empty table), same pattern as has_flag_icon. mdi_window and detail_dialog templates both get the same {{#has_setting_gated_actions}} block: construct the controller, registerAction per row, wire loggedIn=/=reconnected to refresh().

1. Add SettingGatedActionController to ores.qt/api.
2. Migrate currency's CurrencyMdiWindow and CurrencyDetailDialog to use it in place of the duplicated hand-written mechanism.
3. Add the "Setting-gated actions" table + derived has_setting_gated_actions flag (org_loader.py) and the corresponding mustache sections in both cpp_qt_mdi_window.*.mustache and cpp_qt_detail_dialog.*.mustache.
4. Flip it on for currency (generateAction_ / system.synthetic_data_generation, in both templates); regenerate; diff against the migrated hand-written version from step 2.
5. Build passes; acceptance met.

• The actual QAction creation (icon, tooltip, connected slot — generateAction_ = new QAction("Generate", ...) etc.) stays hand-written per entity, same as currency's generateSynthetic()=/ =onGenerateClicked() feature logic itself. Only the subscribe/notify/query wiring is generalised — regenerating currency's files wholesale today would leave generateAction_ a never-constructed nullptr (the template has no opinion on what the action looks like or does), consistent with the broader "Sync Qt codegen for currency" reconciliation still being incremental, capability-by-capability.
• CurrencyDetailDialog's updateGenerateActionVisibility() had an extra rule the shared controller initially didn't know about — hide in read-only/history mode, rechecked on every visibility update including notification-triggered ones. The first cut of this task only guarded the initial post-login check, which the PR review round correctly flagged as a regression (a live setting-change notification while a read-only history view was open could transiently re-show the action). Resolved by adding an optional guard predicate to registerAction(), ANDed with the setting's value on every refresh() — CurrencyDetailDialog passes [this]{ return !isReadOnly_; }, and the generic detail_dialog template does the same with its own readOnly_ member, so future has_setting_gated_actions consumers get the same protection by default. See PR #1446's review round for the full back-and-forth.
• Verified via codegen entity generate currency --address ores.cpp.qt --diff: the has_setting_gated_actions-gated sections match the hand-migrated code modulo formatting. Did not adopt the full regenerated file set (same pre-existing unrelated drift as the CSV/XML task).
• Lesson from this task: commit hand-migration edits to the actual entity files before running a test full-regenerate-then-revert — git checkout -- reverts to the last commit, not to "before this local experiment," and silently discarded the CurrencyMdiWindow/ CurrencyDetailDialog edits once, requiring a redo.