Task: Delete legacy codegen profile system (facet_catalogue.org, core.py profile path)

Delete System 1 as described in the parent story's Analysis section:

• projects/ores.codegen/library/facet_catalogue.org (id A8145FD7-0651-40FD-857E-BC37C9320020) — the entire file.
• _load_profiles_from_org() in projects/ores.codegen/src/codegen/core.py (around line 520-577) and every function/branch reachable only from it or from the --profile CLI flag (both the compass codegen generate --profile path and the deprecated --profile flag on compass codegen entity generate — check projects/ores.compass/src/compass_codegen*.py for the --profile argparse wiring and remove it too, or leave the flag parsing in place but make it a hard error pointing at --address if removing the flag entirely is too disruptive for muscle memory; use judgement here, the story's real requirement is deleting the dead resolution code, not necessarily the CLI flag string itself).
• get_cpp_junction_template_mappings() in core.py (~line 1094) — this is dead code reachable only through System 1 (see story Analysis). Do not delete it as part of this task, though — the next task (Add junction to model_types on ores.cpp.domain/generator/repository.org) needs to look at it as reference for what fields a junction needs mapped, since it is the only existing (if untested) attempt at junction C++ template mapping in the codebase. Leave it in place for that task to consume/replace, and note in this task's Result whichever way it went so the next task doesn't waste time rediscovering it.

Do this deletion first, before starting the junction-support tasks — the story's explicit ordering rationale: deleting first, then building new junction support on the clean system, means any breakage the deletion causes is diagnosed against a system with no new in-progress junction changes to confound the diagnosis.

After deleting, regenerate a handful of existing entities across a few different components (e.g. one from ores.refdata, one from ores.trading, one from ores.marketdata) via compass codegen entity generate <name> and diff against git HEAD — expect zero diff. If anything differs, that's this task's own regression, not an acceptable side effect (see the parent story's Acceptance).

• facet_catalogue.org is deleted.
• _load_profiles_from_org() and its exclusive call chain are deleted from core.py.
• get_cpp_junction_template_mappings() is explicitly left in place (noted above) for the follow-on junction-support tasks to consume.
• Regenerating a sample of existing entities across a few components produces zero diff against HEAD.
• Any script/doc that referenced --profile or facet_catalogue.org either still works (if the flag is kept as a hard-error shim) or is updated to use --address — full sweep of every such reference is the separate Sweep docs/skills/recipes task, but this task must not leave the build itself broken (e.g. a CI script invoking --profile directly) — grep for --profile across projects/ores.compass, .github/workflows, and any Makefile/shell wrapper before deleting, and fix those specific call sites as part of this task even though the broader doc sweep is separate.

1. Grepped _load_profiles_from_org=/=load_profiles=/=facet_catalogue across projects/ores.codegen and projects/ores.compass: confirmed load_profiles() (and its exclusive helpers _load_profiles_from_org(), _parse_facet_table(), plus the _FACET_HEADING_RE=/=_FACET_PROP_KEY_RE=/ =_unlink_org=/=_ORG_ID_LINK_RE symbols only they used) has zero callers anywhere in the tree — dead since whenever System 2 replaced it.
2. Grepped --profile in projects/ores.compass: the only live --profile surfaces are (a) the already-deprecated flag on compass_codegen_entity.py (help text already says "DEPRECATED (use –address)" — nothing to fix), and (b) the compass codegen generate/regenerate subcommands' --profile flag in compass.py, which feeds generate.py's resolve_targets() → its own _PROFILE_TO_FACETS backward-compat shim (a different, still-live mechanism, unrelated to facet_catalogue.org=/=_load_profiles_from_org — migrating its callers to --address is task B11's job, not this one). So this task's acceptance criterion ("fix those specific call sites") had nothing to fix: deleting the dead code doesn't touch any working --profile call site.
3. Deleted load_profiles(), _load_profiles_from_org(), _parse_facet_table(), and their exclusive helper symbols from core.py. Left get_cpp_junction_template_mappings() (~line 1011) untouched, per this task's Goal.
4. Did not delete facet_catalogue.org itself. A grep for inbound id: links to its file id (A8145FD7-0651-40FD-857E-BC37C9320020) turned up ~80 files across doc/, projects/ores.codegen/library/templates/, and projects/modeling/ — real blast radius requiring careful content-porting and link-repointing, which is exactly what task B10 ("Retire facet_catalogue.org file + legacy literate facet/group docs", moved into this story from "Resolve codegen model unification blockers" — see below) is already scoped and equipped to do properly. Narrowed B10's own doc to reflect that its Python-deletion half is done here; it now owns only the file + link work.
5. Verified via compass codegen entity generate: regenerated book (refdata) with both a narrow --address ores.cpp.domain and the full default supported set — zero diff both times. Attempted the same for floating_index_type (trading) and market_fixing (marketdata) and got real diffs/untracked files — but confirmed by stashing this task's change and regenerating the same two entities against unmodified HEAD that the exact same drift is present there too. Pre-existing, unrelated to this deletion; filed as a backlog capture (audit_marketdata_cpp_drift.org) rather than fixed ad hoc, since the "Refactor ores.codegen C++ generation" story already owns this class of drift with its own audit-then-apply methodology.
6. Discovered mid-task that a different story, "Resolve codegen model unification blockers", had two BACKLOG tasks (B10, B11) essentially duplicating this task and task 5's scope. Reconciled per user instruction: moved that story's 8 remaining BACKLOG tasks (B4, B6, B7, B9, B10, B11, the _table.org content migration, and table-type retirement) into this story via compass task move, then closed the donor story DONE with a * Result explaining the merge. See this story's own * Decisions for the reconciliation notes on B10/B11.

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.

load_profiles()=/=_load_profiles_from_org()=/=_parse_facet_table() and their exclusive helper regexes/functions are deleted from core.py (confirmed zero live callers before deletion). get_cpp_junction_template_mappings() is left in place for the next task. facet_catalogue.org itself is intentionally not deleted — its ~80 inbound id: links make that a separate, properly-scoped piece of work, now owned by task B10 in this same story (moved in from "Resolve codegen model unification blockers", which this task also triggered merging in full — see the parent story's * Decisions). Regenerating book (refdata) confirmed byte-identical output before and after the deletion, at both a narrow --address and the full supported set. Pre-existing drift found while sampling floating_index_type=/=market_fixing was verified unrelated (present on unmodified HEAD too) and filed as a backlog capture rather than fixed here. No --profile call site needed fixing: the only working --profile surfaces route through a separate, still-live shim in generate.py that this task's deletion doesn't touch.