Task: Investigate decommissioning ores.controller.service and its DB tables

The split-services-into-per-service-containers story moved process launch/lifecycle from ores.controller.service=/=process_supervisor to systemd cascading. That story's own follow-up work is tracked elsewhere; this task is specifically about auditing what's left over in the DB/codebase now that the controller no longer launches anything: is the ores.controller.service binary/=process_supervisor= code itself still built and shipped, and are there any ores_controller_* tables/columns that are genuinely dead (not the service_definitions=/=service_dependencies tables, which systemd_generate.py actively reads as its source of truth)?

• Inventory: is ores.controller.service=/=process_supervisor still built/deployed anywhere, or already fully replaced by systemd?
• Inventory: which ores_controller_* DB tables/columns are still load-bearing (service_definitions=/=service_dependencies, read by systemd_generate.py) vs. genuinely dead.
• A decision recorded (here or as a follow-up task) on what to actually remove, with nothing removed speculatively before this audit confirms it's dead.

1. Grep the full repo (excluding build/, venv/) for process_supervisor and ores.controller references in code, CMake, and SQL, and check projects/ for any remaining ores.controller* directory.
2. Enumerate every ores_controller_* table (projects/ores.sql/create/controller/) and grep the full repo for readers/writers of each.
3. Cross-reference against systemd_generate.py to confirm which tables it actually reads.
4. Record findings and file a follow-up capture for anything found dead, rather than removing it in this audit-only task.

Confirmed the binary/code side is already fully gone – this was Sprint 24's decommission-controller-service task (PR #1806): no projects/ores.controller* directory exists, and the only remaining process_supervisor=/=ores.controller string hits in the whole repo (outside build/) are historical/documentary, in systemd_generate.py's and compass_services.py's own docstrings explaining why the DB-driven systemd approach replaced it, and in how_do_i_start_services.org, which already states plainly that ores.controller.service=/=process_supervisor "were decommissioned once this landed."

DB side: projects/ores.sql/create/controller/ has four tables –

• ores_controller_service_definitions_tbl and ores_controller_service_dependencies_tbl – confirmed still load-bearing: systemd_generate.py's fetch_service_definitions()=/ =fetch_dependencies() query them live as the source of truth for compass systemd generate. Not dead, and not this task's to touch; a separate capture (6E3720AB, already filed) proposes moving this static topology into a codegen model instead of a DB round-trip – a bigger, separate piece of work.
• ores_controller_service_instances_tbl (PID/phase/restart-count bookkeeping, one row per running instance) and ores_controller_service_events_tbl (a TimescaleDB hypertable event log of start/stop/crash transitions) – genuinely dead. Both were the controller's own Kubernetes-style Pod/Event bookkeeping for processes it launched and supervised; a full-repo grep for both table names found zero readers or writers anywhere in C++, Python, or SQL. systemd's own unit state and journal replaced this function entirely; nothing populates or queries these tables post-migration.

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.

Audit complete, decision recorded, nothing removed speculatively:

• ores.controller.service=/=process_supervisor binary and code: 100% gone already (Sprint 24, PR #1806). No further action.
• ores_controller_service_definitions_tbl=/=dependencies_tbl: still load-bearing (systemd_generate.py's source of truth). Not touched; their eventual codegen migration is tracked separately (capture 6E3720AB).
• ores_controller_service_instances_tbl=/=events_tbl: genuinely dead, zero remaining readers/writers repo-wide. Filed as a follow-up capture rather than dropped here, since dropping tables is a real migration (projects/ores.sql/drop/controller/ already has the drop scripts ready) that deserves its own task/PR, not a speculative deletion tacked onto an audit-only task. See Drop dead ores_controller_service_instances_tbl/events_tbl.