feat: a no-op expire answers from the column's extent, not a zone-map probe per group (#1310)

[OffgridwithJD]

Fixes #1310. #1325 has merged, so this is now rebased onto main (11f954e): six commits, starting at 0e32c6c.

What it does

This follows the plan you wrote on #1310. Most of the daemon's passes retire nothing, and expire proved that with one zone-map probe per row group. When the retention column's extent puts its minimum at or past the cutoff, no group's maximum is below it, so nothing can qualify, and expire returns 0 after one index lookup. Otherwise it decides group by group, as before. A column with no value at all has nothing to retire either. A too-wide extent only means no early exit; with no complete extent the loop runs as before.

Measured as zone-map scans for a no-op expire over 50 groups: 50 before, 0 after.

Arms, in both twins (the names match; the fixtures differ)

• a no-op expire reads no zone map when the extent's minimum is past the cutoff (red first: 50 scans, 40 in the twin)
• without the extent, the same expire probes every group's zone map
• with the extent, expire retires the same groups as without it
• expire in the transaction that wrote aged rows retires their groups. This relies on feat: a per-column extent the planner reads in one lookup, recomputed whenever groups go (#1304 option 5) #1325's own-transaction fold.
• a later expire on a column of only NULLs reads no zone map

Mutations (PG17), each red on its own arms

mutation	red
early exit removed (the tree before this PR)	the no-op arm, the NULL arm
the extent's maximum compared instead of its minimum	14, including both "same groups" arms and 12 of the suite's existing arms
exit not taken for a column with no value	the NULL arm
#1325's own-transaction fold removed	"expire in the transaction that wrote aged rows"

Your two answers on #1304, applied

• ttl_expire enters the ledger. All 67 checks are in, 16 dated by the four mutations, and no premise is dated. suites_not_covered goes 247 → 246, and the census goes 1745 → 1796 over 2259 rows. The gate gives rc=0.
• premise: expire retired the three aged groups is now an arm, in both twins (expire retired the three aged groups). The max-for-min mutation reddens it.

Evidence

• ttl_expire.sh 67/67 and test_ttl_expire.py 9/9 on PG15–19.
• Re-run on PG17 on this rebased tree: 67/67, and both twins (ttl_expire, column_extent) 16/16.
• expire's extent bounds are initialised, the same LTO maybe-uninitialized shape feat: a per-column extent the planner reads in one lookup, recomputed whenever groups go (#1304 option 5) #1325's review found in the planner.
• Guard half 419/419. cluster_tests 524 → 525, by collection. TESTS.md section 78 and the CHANGELOG are updated.

🤖 Generated with Claude Code

[OffgridwithJD]

@jdatcmd #1325 merged, so this is rebased onto 11f954e. It is now just this PR's six commits, at 4fd0480. The tree is byte-identical to the one verified at 6e81d07 (git diff is empty), because main at 11f954e equals 3c71b6a. That earlier verification gave, on PG17: ttl_expire 67/67, column_extent 36/36, both twins 16/16, and the gate rc=0. Over 15–19, ttl_expire gave 67/67 and its twin 9/9. Ready for your review.

[jdatcmd]

Approved at 4fd0480. Merging when CI is green on this head.

The early exit is sound. The loop retires a group only when its maximum is strictly below the cutoff (c < 0). Every group's maximum is at least the extent's minimum, so min >= cutoff means no group can qualify, and that includes the case where they are equal. A column with no values exits too, and the loop agrees: it skips every group without a min/max. The same active snapshot serves the extent and the loop, and a too-wide extent costs only the early exit.

The ledger is right. Main's 2192 rows are unchanged. ttl_expire enters with 67 rows: 2259 in all, of which 1796 are never red, matching the budget. suites_not_covered goes from 247 to 246. The renamed premise is now an arm, and a mutation is what dates it (#1236).

The twins match. Both carry the six new or renamed checks with identical names, and the pytest file states it is independent of ttl_expire.sh.

I checked this by reading and by the ledger arithmetic. I did not run the suites locally; CI's suites jobs are the run.