db: raise env_builds.status statistics target

[ValentaTomas]

Same treatment as env_builds.status_group (20260725100500): the column's rare values can drop out of the MCV list on an unlucky autoanalyze sample, leaving the planner to underestimate them by orders of magnitude on status-filtered queries. A larger per-column sample keeps every value visible across re-samples; the migration re-analyzes immediately.

[cursor]

PR Summary

Low Risk
Operational DDL only (column statistics and ANALYZE) with no application logic or schema shape changes; brief extra load during migration ANALYZE.

Overview
This migration applies the same planner fix used for status_group: it increases the statistics target on env_builds.status to 2000 so skewed, low-frequency status values are less likely to disappear from the MCV list after autoanalyze, which was causing severe underestimates on queries that filter by status. It runs ANALYZE right away (outside a transaction, with a bounded statement_timeout) and restores the migrator session timeout afterward; the down path resets the target to default and re-analyzes.

^{Reviewed by Cursor Bugbot for commit 3e2e8f9. Bugbot is set up for automated code reviews on this repo. Configure here.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[claude]

LGTM — straightforward, mechanical migration that mirrors the already-merged status_group statistics fix (20260725100500), applied to the env_builds.status column.

What was reviewed: the migration structure (NO TRANSACTION, bounded statement_timeout, ANALYZE, timeout restore, down path) is byte-for-byte consistent with the precedent migration; SET STATISTICS 2000 and the down path's -1 (revert to default) are correct Postgres semantics; no application code, queries, or schema shape changes are involved.

Extended reasoning...

Overview

Single new migration file that raises the statistics target on env_builds.status from default to 2000 and immediately re-analyzes the table. It is a direct copy of the pattern established in the already-merged 20260725100500_env_builds_status_group_statistics.sql migration, just applied to a different column (status instead of status_group). Up path: NO TRANSACTION, bump statement_timeout to 1h, ALTER COLUMN ... SET STATISTICS 2000, ANALYZE, restore statement_timeout to 3h (the migrator's baseline). Down path mirrors this, resetting statistics to -1 (Postgres default sentinel) and re-analyzing.

Security risks

None. This is operational DDL affecting query planner statistics only — no data exposure, no auth/permission changes, no new inputs or code paths.

Level of scrutiny

Low. This is infra/ops tooling for planner behavior, not production business logic, and follows a precedent already reviewed and merged for the sibling column. The only things worth checking — transaction handling for ANALYZE, timeout bounds, and reversibility of the down migration — all match the prior accepted pattern exactly.

Other factors

No CODEOWNER-sensitive paths, no schema shape change (statistics target changes don't require a table rewrite or lock beyond a brief catalog update), and the down migration is a clean, safe revert. Cursor's automated review also flagged it as low risk. Given the exact structural precedent, no human-blocking concerns exist.