Compute Grid End-to-End Improvements

• Complete the eventing pipeline for workunit and result entities so that list windows mark themselves stale on server-side changes.
• Ensure UUIDs are generated correctly for all new compute entities.
• Make the change reason dialog symmetric: shown for all operation types (create, amend, delete), driven by data, with no code duplication across dialogs.
• Add a platforms junction table for app versions.
• Add combo boxes for app selection in app_version dialogs and batch/app_version selection in workunit dialogs.
• Provide SQL scripts to seed the ORE application and its standard platform entries.

All work is confined to: ores.compute, ores.compute.service, ores.qt, ores.dq, and ores.sql.

WorkunitController and ResultController pass std::string_view{} (empty) to EntityController, so they never subscribe to change notifications. List windows therefore never mark themselves stale and users must manually reload.

The DB notification triggers already exist:

• compute_workunits_notify_trigger_create.sql
• compute_results_notify_trigger_create.sql

The missing pieces are: event type structs, registration in the service application, and controller subscriptions.

Note: app, app_version, and batch already have full eventing and require no changes.

[compute] Add eventing for workunit and result entities

App versions (and possibly batches, workunits) are created with all-zeros UUIDs because the Qt detail dialogs send an empty boost::uuids::uuid{} instead of a random UUID.

In each detail dialog's onSaveClicked() (or wherever the domain object is constructed for the save request), check if the UUID is nil and generate one if so:

#include <boost/uuid/random_generator.hpp>

// When constructing a new entity (isAddMode_):
if (entity.id.is_nil())
    entity.id = boost::uuids::random_generator{}();

Files to check and fix:

• AppVersionDetailDialog.cpp
• BatchDetailDialog.cpp
• WorkunitDetailDialog.cpp
• AppDetailDialog.cpp (verify)

Alternatively, the server-side stamp() function could generate missing UUIDs. Check whether the handlers call stamp() before insert and whether stamp() already handles nil UUIDs. If not, add UUID generation there so the fix is centralised.

[compute] Fix UUID generation for new compute entities

The current design is inconsistent across dialogs and operation types:

• Change reasons are only shown for amend and delete; new records silently default to system.new_record (hardcoded).
• The change_reason domain type has applies_to_amend and applies_to_delete booleans but no applies_to_new, so there is no data-driven way to determine which reasons apply to create operations.
• The change reason prompt is copy-pasted into every detail dialog's onSaveClicked(), leading to drift and duplication across all entities.

The solution has three layers:

1. Data model: add applies_to_new to the change_reason domain type and SQL schema, seed system.new_record and system.initial_load with applies_to_new = true.
2. Cache: add getReasonsForNew(category_code) to ChangeReasonCache, matching the existing getReasonsForAmend / getReasonsForDelete pattern.
3. UI centralisation: add promptChangeReason() to DetailDialogBase as a single protected helper that encapsulates the entire dialog flow for all three operation types. Every detail dialog calls this one method; no duplication.

[dq] Add applies_to_new to change_reason domain type and SQL schema
[qt] Add ChangeReasonCache::getReasonsForNew
[qt] Add ChangeReasonDialog::Create operation type
[qt] Add DetailDialogBase::promptChangeReason helper
[qt] Use promptChangeReason in all detail dialogs
[compute] Wire ChangeReasonCache into compute controllers

The platform field on app_version is currently a plain string. For the ORE use case, a single app version may support multiple platforms (e.g., linux-x86_64, linux-arm64). A junction table is needed.

[compute] Add platform junction table for app versions

The AppVersionDetailDialog has an app_id field displayed as a plain UUID text box. Users cannot identify which app an app version belongs to and cannot select a parent app when creating a new one.

• In AppVersionDetailDialog, replace the app_id line edit with a QComboBox populated with (name → id) pairs from a list_apps_request.
• Use LookupFetcher to fetch apps asynchronously before the dialog becomes interactive (same pattern as business-centre combos in PartyDetailDialog).
• Display the app name; store the UUID internally.
• In read-only mode, show the app name as a label.

[qt] Add app combo box to AppVersionDetailDialog

WorkunitDetailDialog displays batch_id and app_version_id as plain UUID text boxes. Users cannot select from available batches and app versions.

• Add a batch_id QComboBox populated with (external_ref → id) pairs via list_batches_request. Filter to active batches only.
• Add an app_version_id QComboBox populated with (app_name + version → id) pairs via list_app_versions_request.
• Both combos fetched via LookupFetcher before the dialog becomes interactive.
• Display human-readable text; store UUID internally.

[qt] Add batch and app_version combo boxes to WorkunitDetailDialog

The ORE application and its standard app version need to be created in the database before any workunits can be submitted. Doing this manually through the UI is error-prone and not repeatable.

Create a JSON metadata file external/packages/ore/metadata.json:

{
  "application": {
    "id": "<stable-uuid>",
    "name": "ORE",
    "description": "Open Source Risk Engine — QuantLib-based risk analytics engine for market risk, counterparty credit risk, XVA, and sensitivity analysis."
  },
  "app_versions": [
    {
      "id": "<stable-uuid>",
      "wrapper_version": "1.0.0",
      "engine_version": "9.0.0",
      "package_uri": "https://ore.example.com/packages/ore-9.0.0-linux-x86_64.tar.gz",
      "platforms": ["linux-x86_64"],
      "min_ram_mb": 512
    }
  ]
}

A hand-written seed script reads this data and produces idempotent INSERTs:

-- projects/ores.sql/seed/compute/compute_ore_app_seed.sql
insert into ores_compute_apps_tbl
    (id, tenant_id, name, description, version, modified_by, performed_by, recorded_at)
values (
    '<stable-uuid>',
    ores_iam_system_tenant_id_fn(),
    'ORE',
    'Open Source Risk Engine — ...',
    1, 'system', 'system', now()
) on conflict (id) do nothing;
-- app_version and platform rows follow

The seed script is applied by recreate_database.sh after schema creation. UUIDs are hardcoded in the metadata so the seed is always idempotent.

[sql] Add ORE application and app version seed data