Cost the columnar scan properly when no seqscan path survives (#171)

[jdatcmd]

Closes the first half of #171.

The defect

A point lookup on an indexed columnar table went from 23.75 ms to 1251.88 ms the moment the table had statistics. Collecting statistics, which #159 made work, made this query shape dramatically worse.

The custom scan path inherits the sequential scan's cost. When there was no seqscan path to inherit from, it fell back to rel->rows -- an output row count used as a cost.

That fallback is not the rare case it looks like. add_path frees a path it finds dominated, so the seqscan is already gone from rel->pathlist by the time the hook runs exactly when some index path beat it on both cost and pathkeys. Which is to say: precisely on the selective lookups where using the index matters most.

Before ANALYZE the row estimate was a large default, and the resulting "cost" was accidentally large enough to lose. With real statistics a selective predicate estimates one row, so a full scan of the table was priced at 1.00:

== BEFORE ANALYZE ==
 Index Scan using cz_id on cz  (cost=0.42..174.29 rows=1250) (actual rows=1)
== AFTER ANALYZE ==
 Custom Scan (ColumnarScan) on cz  (cost=0.00..1.00 rows=1) (actual rows=1)
   Rows Removed by Filter: 249999

A seq scan of that same query costs 2513.00. The custom scan claimed 1.00 and won.

The fix

The fallback now costs the work it actually does: every page read once, and the restriction evaluated on every row. That is core's own seqscan formula, which is why the two agree exactly where both can be observed. Where a seqscan path does survive, nothing changes.

After the fix, the same lookup plans Index Scan using cz_id on cz (cost=0.42..8.44 rows=1).

Tests

Two checks in test/analyze_stats.sh, both behavioural rather than assertions about a cost number, so neither can be satisfied by a differently-shaped wrong cost.

The second one compares the same query against itself with the index denied, rather than against a fixed number of rows. A fixed threshold would only separate the two cases for as long as a row group happened to be larger than it; this stays discriminating whatever the group size is.

Proven by removal. With the fix reverted, both fail and nothing else does:

-- point-lookup plan after ANALYZE: Custom Scan (ColumnarScan) on as_c
FAIL  a point lookup on an indexed column still uses the index after ANALYZE
-- rows discarded to return one row: 9999 with the index, 9999 without it
FAIL  having an index available saves the point lookup real work

With the fix: Index Scan using as_c_id, and 0 with the index, 9999 without it.

Gate

• Build preflight: 15, 16, 17, 18, 19, zero warnings.
• Full suite: 79 pass, 0 fail on PG18 and 79 pass, 0 fail on PG19.

The gate tree predates #170 landing; the two changes touch disjoint files (columnar_customscan.c here, columnar_vector.c there). I will run the full suite on main after this merges to cover the combination.

Still open on #171

The second half -- ANALYZE itself taking tens of minutes on wide tables -- is not addressed here. It has not reproduced inside the benchmark and needs its own investigation. The issue stays open for it.