Story: Retire legacy codegen profile system; add junction support to physical-space codegen

Two parallel codegen systems currently coexist, and one of them is dead code that nobody notices is dead because it silently no-ops instead of erroring. This story deletes the dead one (forcing anything that secretly depended on it to break loudly) and then adds real C++ generation support for junction models to the live system, so a junction entity like tenor_convention_resolution gets a generated domain/repository layer instead of hand-authored code standing in for a codegen gap.

Investigated while trying to get compass codegen entity generate tenor_convention_resolution to produce a C++ repository (not just SQL) for a junction model. Two independent systems exist side by side:

• facet_catalogue.org and core.py's _load_profiles_from_org() / --profile code path (System 1) are deleted outright — not deprecated, not left dormant. Anything that turns out to secretly depend on it breaks immediately and loudly (a missing function, a failed import, a CLI error) rather than silently no-op'ing the way the --profile-editing experiment above did. This is deliberate: the point is to surface every remaining dependency on the dead system by breaking it, not to guess at them in advance.
• Every existing *_domain_entity.org=/=*_junction.org=/etc. model file and every already-generated =.hpp=/.cpp=/=.sql= file in the tree is left completely untouched by the deletion — this story removes dead tooling code, not generated artefacts or their source models. If deleting System 1 causes regeneration of any existing entity to produce a diff, that is a bug in this story's deletion, not an acceptable side effect.
• compass codegen entity generate <any-existing-entity> (a sample of a few, across a few components) is re-run after the deletion and produces byte-identical output to before, proving System 1 truly wasn't load-bearing for anything currently generated.
• ores.cpp.domain.org, ores.cpp.generator.org, and ores.cpp.repository.org (at minimum — service/protocol/qt deliberately excluded, matching get_cpp_junction_template_mappings's own documented scope decision, unless investigation says otherwise) gain junction in their #+model_types:, are re-tangled, and their templates are fixed/adapted as needed so junction generation actually produces compilable, correct C++.
• Validated end-to-end against a real junction: projects/ores.marketdata/modeling/ores.marketdata.tenor_convention_resolution.org (id E1F5A9C3-6D2B-4E8A-B7F1-3C9D5A2E6B48) regenerates a domain struct + repository (at minimum read_all=/=read_latest-style queries; write support if the templates naturally produce it, though this junction's own data is Foundation-layer-managed and doesn't strictly need writes). Diff the generated repository/entity against the hand-authored reference files listed below to sanity-check field names, types, and query shape — then delete the hand-authored files and switch projects/ores.marketdata/core/src/messaging/registrar.cpp and the hand-authored service/protocol/handler (added in the Tenor management UI task) to use the generated repository instead.
• No regression to any of the ~83 existing domain_entity models or ~8 existing junction models' generated output (see Acceptance bullet 3 above) — this is a strictly additive change to what junctions can generate, not a reshuffle of what entities already generate.

• Merged in "Resolve codegen model unification blockers" (2026-07-15): while starting task 1, discovered that story had two BACKLOG tasks (B10, B11) duplicating this story's tasks 1 and 5 almost exactly, plus six more BACKLOG blockers (B4, B6/archetypes subcommand, B7, B9, the _table.org content migration, table-model-type retirement) in the same "retire legacy codegen cruft" vein. Rather than track overlapping work in two stories, moved all 8 (via compass task move, UUIDs intact) into this story and closed the donor DONE. B10 was narrowed since task 1 already deleted its Python half (load_profiles=/=_load_profiles_from_org); B11 was left standing alongside task 5 with a delineation note, since it covers migrating working --profile callers to --address — a different, still-live shim (_PROFILE_TO_FACETS in generate.py) from the dead System 1 task 5 sweeps stale prose about.
• Delete, don't deprecate. Explicit user instruction: rather than leaving System 1 in place as unused-but-harmless code, delete it outright so that anything still secretly depending on it breaks immediately and visibly, rather than continuing to silently work by accident (or silently not work, as the facet_catalogue.org edit-with-no-effect experiment demonstrated) until someone notices much later.
• Keep every existing model and generated artefact untouched. This story is scoped to the codegen tooling, not to any entity's generated output. Explicit user instruction: "keep the legacy models and generated code" — only the dead resolution code path and the legacy catalogue doc are in scope for deletion.
• Junction gets domain/generator/repository, not service/protocol/qt, as the initial scope — matching what get_cpp_junction_template_mappings's own docstring already documents as the intended design ("do not generate service or protocol files"). A junction's rows are meant to be read through a parent entity's service, not exposed as their own top-level NATS endpoint — the Tenor management UI task's hand-authored service is the concrete counter-example motivating this story, and if that pattern turns out to be needed generally (not just for this one screen), that is a separate, later decision about whether to widen junction codegen scope further, not something to fold into this story's initial pass.

• Any change to what an existing domain_entity or already-supported junction (SQL-only) model generates today — covered by the regression-check acceptance bullet.
• Widening junction generation to service/protocol/qt facets — out of scope unless the domain/generator/repository work reveals it's actually needed sooner than expected (see Decisions).
• Fixing the IMM_ROLL tenor resolution algorithm or seeding credit/CDS resolution rows — unrelated, tracked separately in the capture Implement IMM_ROLL tenor resolution for credit/CDS conventions.
• Finishing the Tenor management UI itself — tracked in Tenor management UI task, which this story unblocks (that task can proceed now with a hand-authored service/protocol/handler as a stopgap, per the user's explicit "continue your work manually" instruction, and switch to the generated repository once this story lands).

Closed DONE: this story's own Acceptance is fully met by tasks 1-4. System 1 (facet_catalogue.org's dead resolution code) is deleted; junction C++ generation (domain/generator/repository) works and is validated end-to-end against a real junction (tenor_convention_resolution), which now runs on generated code with the hand-authored stopgap retired; no regression to any existing domain_entity=/=junction model's generated output (book verified zero-diff throughout, plus the full ores.refdata test suite passing). Task 4's manual Tenor management UI screen check was skipped per explicit user instruction (an unrelated build-target issue interrupted starting the client; the service/protocol contract is unchanged by this story's work, so the risk is low) – left for whoever next runs that screen to confirm.

Merged-in work retained here: task 5 (sweep docs/skills/recipes for stale legacy-profile-system references) and 4 of the 8 tasks merged in from "Resolve codegen model unification blockers" – B4, B6, B10, B11, and the _table.org content migration – all now DONE. None of these were required by this story's own Acceptance criteria; B10/B11 in particular were near-duplicates of tasks 1/5's scope.

Split into a follow-up story at health review 1 (2026-07-20, once DONE-heavy but not fully closed): B7 (split-model backward- compatibility, itself completed DONE and absorbing the duplicate table-model-type task as ABANDONED), B9 (mustache-to-address rename), and the remaining junction-codegen rollout task, moved via compass task move to Codegen legacy-profile retirement follow-ups so this story's own finish line didn't keep expanding.