Zone maps keep the old collation after ALTER COLUMN ... COLLATE, so queries return wrong results #1327

Wrong results after a collation change that does not rewrite the table

What happens: ALTER COLUMN ... TYPE text COLLATE <other> on a columnar table keeps the relfilenode. The zone maps keep the old collation's min and max, so chunk-group pruning and min/max skip rows the new collation orders differently.

Reproduced on main at 036d452, PG17:

CREATE TABLE c (s text COLLATE "C") USING pgcolumnar;
INSERT INTO c VALUES ('a'), ('B'), ('m'), ('b');
CREATE TABLE h (s text COLLATE "C");
INSERT INTO h VALUES ('a'), ('B'), ('m'), ('b');
ALTER TABLE c ALTER COLUMN s TYPE text COLLATE "en_US.utf8";   -- relfilenode 16548 before and after
ALTER TABLE h ALTER COLUMN s TYPE text COLLATE "en_US.utf8";
SELECT min(s) || '|' || max(s) FROM c;                          -- B|m   (heap: a|m)
SELECT string_agg(s, ',' ORDER BY s) FROM c WHERE s < 'B';      -- empty (heap: a,b)

Expected: the same answers as heap.

Possible fixes, not chosen:

• force a rewrite, or invalidate the column's zone maps, when a column's collation changes;
• or store the collation with each zone map and ignore a mismatched one.

Arm to add first, in both twins: change a column's collation without a rewrite, then require min, max and a WHERE s < 'B' to equal heap's.

Found while reviewing #1325, whose column_extent() would print the same narrow bound. That PR's planner bound reads only timestamp columns, so the bug is not that PR's.