JobLog retention check via data integrity framework (#1188) #1277

Background

PR #1259 moves job-log persistence onto an append-only JobLog child table. Drops the old per-job max_log_length = 1000 ceiling that the JSONB write path enforced. New table grows unbounded — needs explicit retention, otherwise high-traffic deployments will accumulate pathologically large jobs_joblog.

Approach

Implement retention as a module under the data integrity check framework being introduced in #1188 — ami/main/checks/joblogs.py:

• get_joblog_retention_violations(project_id=None, max_age_days=N) — returns rows past the cutoff
• reconcile_joblog_retention(..., dry_run=True) — deletes excess rows, returns IntegrityCheckResult(checked, fixed, unfixable)

Plugs into the check_data_integrity management command and the Celery beat hook that #1188 already wires up. No new periodic task or CLI surface.

Caps

• Per-request read cap (already shipped in Refactor job logging to use separate table #1259): 1000 rows per response (JOB_LOGS_DEFAULT_LIMIT). UI paginates older entries later.
• Per-job storage cap: none. Decision in Refactor job logging to use separate table #1259 review — the read cap + an age-based prune is sufficient; per-job ceilings re-introduce the ceiling drift we just removed.
• Age-based prune: open question. Suggest 30d or 90d default, configurable via setting. Discuss before merging the retention check.

Schedule

Default to manual (--no-dry-run only via the management command) until soak. Wire to beat after one cycle of running it by hand.

Acceptance

• ami/main/checks/joblogs.py with get_* / reconcile_* pair
• Tests under ami/main/tests.py::TestIntegrityChecks mirroring the occurrences module
• Default age cap chosen + documented
• PR body links Refactor job logging to use separate table #1259 and Framework to check and report data integrity issues #1188

Blocked by

• Framework to check and report data integrity issues #1188 (data integrity check framework)