fix(api): stop writing pre-013 investigation columns and remove approvals

[bordumb]

Summary

Since 013_unified_investigation.sql, investigations only has id, tenant_id, alert, main_branch_id, outcome, created_at, created_by, root_hash plus a generated status. Four call sites still used the old schema and failed at runtime:

1. Snapshot import (POST /investigations/import) wrote a value into the generated status column (GeneratedAlwaysError). It now leaves status to derive from outcome.

2. EE spawn_investigation automation action queried investigations.issue_id and inserted status/source/metadata. It now:

   • builds a valid AnomalyAlert from the issue and starts the investigation through InvestigationStarterService (which inserts the row and starts the Temporal workflow);
   • links the issue via issue_investigation_runs (trigger_type='rule') and reuses an existing run if there is one;
   • takes the datasource from a datasource_id action param, or the tenant's only active datasource. Any other case fails the action, and so does a datasource from another tenant.

   ExecutionContext gains a required investigation_starter. Note: execute_actions has no production caller yet.

3. AppDatabase.create_investigation: no callers; deleted.

4. The approvals stack: deleted. It targeted the pre-013 approval_requests table, which 013 re-keyed on branch/snapshot ids that Temporal investigations never create, and nothing creates approval requests. Temporal's human-in-the-loop path is POST /investigations/{id}/input. Removed:

   • the /approvals routes;
   • the AppDatabase approval methods and update_investigation_status;
   • the dashboard pending_approvals stat (API + card);
   • the unused approval notification producers (service, email, Slack);
   • ContextReviewPage with its route, the approval link in notifications, and the settings toggles.

OpenAPI: only the approvals paths, their 7 schemas and pending_approvals were removed from the committed spec. A full just generate-client pulls in thousands of lines of unrelated drift. The client was regenerated from the edited spec with orval, and the 23 stale approval files and index exports were removed by hand.

Tests

Written first against the real migrated schema (migrated_db), and each failed for the expected reason before its fix:

• tests/integration/api/test_investigation_snapshot_import.py: failed with GeneratedAlwaysError.
• EE tests/integration/core/automation/test_spawn_investigation.py, 6 cases: failed with column "issue_id" does not exist.

tests/integration/conftest.py is byte-identical to the one in #162. EE integration tests load that module by path, since both packages have a tests.integration package.

Verified on main 8cd71078:

• CE pytest: 2122 passed, 38 skipped
• EE pytest: 470 passed
• Integration: 7/7
• mypy: clean
• ruff and ruff format (venv 0.14 and hook 0.3.0): clean
• Frontend: tsc, eslint and vitest all clean

Merge notes

• fix(api): use dataset_ids consistently for investigation alerts #159 / fix(api): list dataset investigations from the alert JSONB #160 add the older version of tests/integration/conftest.py, which differs from ci: run integration tests on a migrated database and fix frontend hooks #162's. This PR's copy matches ci: run integration tests on a migrated database and fix frontend hooks #162.
• feat(api): enforce org roles on every mutating route and in the UI #150 / fix(core): encrypt git repository access tokens at rest #151: test_route_authorization.py POLICY lists the 4 ("POST", "/approvals/...") routes, and test_policy_lists_every_mutating_route asserts set equality. Whichever of the two PRs merges second must drop those 4 entries. dashboard-page.test.tsx mocks pendingApprovals: 0, which is harmless but can go.
• Feat/fn 56 dataing assistant #128 (fn-56) still reads stats?.pendingApprovals and ships an openapi.json that includes approvals, so both need updating when it's rebased.

🤖 Generated with Claude Code

[vercel]

Deployment failed for project dataing with the following error:

Resource is limited - try again in 24 hours (more than 100, code: "api-deployments-free-per-day").

Learn More: https://vercel.com/bordumbs-projects?upgradeToPro=build-rate-limit

[vercel]

Deployment failed for project dataing-docs with the following error:

Resource is limited - try again in 24 hours (more than 100, code: "api-deployments-free-per-day").

Learn More: https://vercel.com/bordumbs-projects?upgradeToPro=build-rate-limit

[vercel]

Deployment failed for project dataing-app with the following error:

Resource is limited - try again in 24 hours (more than 100, code: "api-deployments-free-per-day").

Learn More: https://vercel.com/bordumbs-projects?upgradeToPro=build-rate-limit