Index-resident, incrementally-maintained summaries (BRIN-style); remove side table + REINDEX

[bitner]

Replaces the side-table + mark-stale + REINDEX maintenance model with self-maintaining, index-resident summaries — the way BRIN works. Follow-up to #1.

What changed

• Summaries live in the index's own metapage (src/index_storage.rs): page I/O via the Generic WAL API + a compact versioned (de)serialization. No side table.
• ambuild scans the leaf and writes the summary to the metapage.
• The planner reads each partition's summary directly from its index page (cached per plan), instead of an SPI load of a side table.
• aminsert widens the summary in place as rows arrive — like BRIN. Because the summary only ever has to be over-inclusive, these updates need no MVCC: an insert within range writes nothing; one that extends it grows min/max (scalars, in-memory) or the extent (range/geometry, via the type's union). Pruning stays correct and active across inserts with no REINDEX.
• Removed: the table_range_summary table, the stale flag + per-transaction memo, and the sql_drop cleanup event trigger (DROP INDEX frees the summary with the index). Deletes leave the summary conservatively wide (safe); VACUUM/REINDEX re-tighten.

Load-bearing dependency discovered

The planner only puts indisvalid indexes into rel->indexlist, which is where the new read path looks. So a table_range index must stay valid for pruning to engage. This never mattered on main (it read a side table by relid) but matters now; it's documented in read_index_summary. (Surfaced while benchmarking against a stale dev DB carrying a pre-main "hide indexes" trigger that marked indexes invalid.)

Planning-cost optimization

The pathlist hook runs once per partition and was re-resolving the btree compare proc (3 syscache lookups) and re-parsing the query constant for every partition. Both are identical across a column's partitions, so they're now memoized per top-level plan. Warm planning for a non-key predicate at 2,000 partitions dropped ~139 ms → ~80 ms (our per-partition overhead roughly halved).

Benchmarks (warm, EXPLAIN ANALYZE, pg18)

vs the old side-table design (main) — no regression. Reading each partition's summary from its index page is as cheap as main's batched side-table load; planning within ~1–3%, execution identical. Pruning's win remains execution: e.g. ~0.4 ms vs ~100 ms at 300×8k-row partitions.

vs native declarative pruning (two identical columns: pk = partition key, nk = same values, non-key + our index):

Partitions	Native (pk) planning	Ours (nk) planning
2,000	0.15 ms	~80 ms (post-optimization)
10,000	0.29 ms	ERROR: out of shared memory

Scaling limitations (documented honestly)

Native pruning is ~constant-time because it prunes on the partition key's sorted bounds before partitions are locked/opened. A non-key predicate forces PG to expand and lock every partition, which is O(n) and exhausts the lock table around ~10k partitions (raise max_locks_per_transaction to push that out). This is inherent to PG's planner — non-key pruning can't be made sub-linear from public hooks. table_range targets the hundreds-to-low-thousands of sizeable partitions, non-key-predicate sweet spot, where it wins big on execution. True tens-of-thousands scaling would need pre-expansion pruning (a core-PG hook), tracked separately.

Tests

29 tests pass on pg18 (insert-correctness tests verify out-of-range inserts widen the page summary so new rows are found and pruning stays active). Production build, clippy -D warnings, and fmt all clean. New tests cover the raw page round-trip and that ambuild persists the summary.