Task: Fix scheduler entity model drift: update to latest format and regenerate

Mirror Fix refdata entity model drift for ores.scheduler: regenerate every ores.scheduler domain_entity and junction model (compass codegen entity list) against current codegen templates. Where a model uses an outdated format/convention rather than the templates having simply moved on, update the model to the current convention before regenerating. Commit the resulting clean tree.

Along the way, apply the same lessons learned fixing refdata's drift: check whether any entity's SQL/domain/messaging layer is explicitly hand-maintained (a doc comment flagging missing paste-block coverage) before doing a full regen – prefer --address-scoped regen for anything so flagged; grep synthetic generators for hardcoded/fabricated soft-FK values (coding scheme codes, lookup-table codes) that don't match what a freshly-recreated default database actually seeds.

• Every ores.scheduler domain_entity and junction model is regenerated via compass codegen entity generate and shows zero diff on a second regen (idempotent).
• Any model found using an outdated format/convention is updated to the current one before regenerating.
• Any entity whose SQL/domain/messaging layer is hand-maintained (flagged in its own model doc, mirroring party's) is excluded from a full regen and only its safe facets (e.g. Qt) are regenerated, same as party's treatment in the refdata task.
• Synthetic generators for FK-referencing fields are checked against actual seed SQL (the default db recreate chain, not optional artefact/dataset scripts) and fixed if they fabricate values that don't exist there.
• compass build and full rat pass after the regenerated files are committed.
• No entity outside scheduler is touched.

Audited every ores.scheduler domain_entity=/=junction model against current codegen templates and the hand-written C++ it maps to. job_definition turned out fully hand-diverged: the model's tenant_id=/=schedule_expression=/=is_active column shapes don't match the hand-written job_definition struct's actual types (std::optional<boost::uuids::uuid>=/=cron_expression=/=bool), so even the "safe" domain/repository-entity/mapper facets would regenerate wrong types, not just wrong formatting. On top of that, repository (read_all_active, find_by_name x2) and messaging (schedule=/=schedule_batch=/=unschedule, custom history, protocol structs in scheduler_protocol.hpp consumed cross-component by ores.reporting) are hand-maintained with no generic equivalent. Mirrored party's hand-maintained-SQL treatment from the refdata drift-fix task, but wider in scope: excluded the whole entity from regeneration (no facet is currently safe) and recorded the exclusion and the reasons in the model file itself, migrating it to the current * Columns=/:primary_key:= property format along the way. No generated code was touched. Confirmed with a full compass build.

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.

job_definition is fully hand-diverged (domain, repository, and messaging layers all hand-maintained with no safe facet to regenerate), so no regeneration was possible or attempted. Migrated the model to the current format/property conventions and documented the exclusion and its reasons directly in the model file, mirroring party's hand-maintained-SQL treatment from the refdata drift-fix task. No generated code changed. compass build passes clean.