test: date twenty never-red checks and rename three fixture facts (#1236)

[jdatcmd]

Part of #1236. Takes ten parts off the reading list: five selftest parts, rewrite_storage_oid, catalog_delete_index, catalog_plan_index, projection_scan_cost and projection_parallel. 20 checks dated, 3 renamed. Rebuilt onto c1e253f after #1285; the census at this head is 1671 -> 1651. The tables below cover the first ten mutations; the second commit's comment covers the rest.

@OffgridwithJD, this needs your review. I will not merge it without your approval on the head commit.

What changed

Part	Never-red checks before	What happened to each
harness_selftest/570	3	1 dated; 2 renamed premise:
harness_selftest/190	1	renamed premise:
harness_selftest/290	2	2 dated
harness_selftest/560	1	1 dated
harness_selftest/580	2	2 dated (both control: arms)
rewrite_storage_oid	2	2 dated

The never-red census at this head moves 1671 -> 1651 (it read 1633 -> 1613 before the rebuild onto #1285).

How each date was measured

Every mutation ran on all five majors, in its own worktree per major, so no two builds shared an object tree or an install prefix. Each log was merged one at a time with --mutation and --target. For every selftest mutation the failed set was identical on all five majors, and every log reconciles at 1213 checks.

Mutation	Reds per major	Previously never
570: _ck_pat relaxed to \.git	5	and unfolded it is invisible…
290: the built N of M line replaced by finished	1	…says how many it built
290: the missing-directory guard answers yes	1	and a directory that is not there holds none
560: pgc_build_and_install's stamp branch becomes elif false	2	and it still consults the stamp…
580: rebuild.sh rewords no such pg_config	2	control: with the exemption present…
580: pgc_symbol_is_toolchain deleted from lib.sh	10	control: and it does NOT blame the exemption, premise: the symbol exemption is exposed…
rewrite_storage_oid: CreateTableAsStmt out of the repair gate	1 on 17, 18, 19; 0 on 15, 16	a matview created WITH DATA…
rewrite_storage_oid: RefreshMatViewStmt out of the repair gate	1 on all five	and REFRESH still leaves it…

The WITH DATA arm is green on 15 and 16 under its mutation, and that is correct. On those majors a new matview is filled in place, so the orphaned storage row cannot happen. The 15 and 16 logs were merged as plain green runs, without the mutation.

The three renames

The owner decided on 2026-10-12 that a check which only describes its own fixture is renamed premise:, not kept as an arm or deleted.

• 570, two checks. They assert that a file printf > just wrote is a regular file and exists. That is POSIX, not pgcolumnar.
• 190, one check. It runs its own copy of the comment strip on a line printf just wrote. Measured, not argued: with the arm's strip replaced by a raw cat, all 1213 selftest checks stayed green on every major. Nothing but the check itself can redden it.

Each rename touches the part and its ledger row. Selftest parts have no pytest twin and no TESTS.md line.

One mistake on my side, and why no result depends on it

My first attempt ran several mutants on one major at once, and then several majors in one worktree at once. The harness refused the first (the installed library is not the one this tree built) and the second failed to load (undefined symbol). I discarded every log from both, and nothing in this PR comes from them. Part 570's mutant logs overlapped one stray run on PG16. I checked all five: 1213 checks each, the same five reds, no guard or symbol message.

Not verified locally

I did not run a clean control of this branch locally, because my mutation queues hold the install prefixes. CI's full matrix is the control, including the ledger gate and the orphan scan.

🤖 Generated with Claude Code

[jdatcmd]

Second commit, eec3199: four more suites

catalog_delete_index, catalog_plan_index, projection_scan_cost and projection_parallel no longer hold a never-red arm. Same method as the first commit, and every mutation's failed set is identical on all five majors.

Suite	Mutation	Reds	Previously never
catalog_delete_index	size check removed in pgcolumnar_scan_index_oid	7	with few catalog pages the drop's default…
catalog_delete_index	index_min_blocks initializer and boot value set to INT_MAX	7	the drop's default does less catalog work…
catalog_plan_index	f5451fa's C change reversed on be31874	3	all three
projection_scan_cost	discount for any clause that mentions the sort key	1	the OR arm
projection_scan_cost	discount gated on exact	1	the IN-list arm
projection_scan_cost	no clause earns the discount	5	plain-range arm, plus two plan premises
projection_parallel	worker never wires the shared counter	1 (16000 for 8000)	returns the covering rows once

The two catalog_delete_index mutations reuse the ledger's existing wording, so the catalogue shows one cause per change.

One arm is named for something it does not check. Under the parallel mutation, workers share the covering projection scan, it is not a single claimer stayed green on every major. With no sharing at all, both workers still produce rows, which is all the arm asks. I have not changed it here; it goes on #1236.

Census: 1633 -> 1624 -> 1613.

🤖 Generated with Claude Code

[jdatcmd]

Rebuilt onto c1e253f after #1285 landed; the head is now 0019286. Nothing in the content changed. The ledger rows come from the same mutation logs, merged again by a script, and that script run on be31874 reproduces eec3199's ledger byte for byte. The census is now 1671 -> 1651 because the base moved: the same 20 checks are dated. The CHANGELOG entries are carried over unchanged.

🤖 Generated with Claude Code

[OffgridwithJD]

Approving 00192864.

Reproduced one of the new dates independently, in my own worktree at this head on PG 16. The mutation is #1210's src/ change reverted (git show f5451fa -- src | git apply -R):

  control   catalog_plan_index   27 passed + 0 failed
  mutant    catalog_plan_index   24 passed + 3 failed
    planning over the newest columnar table did not sequentially scan pgcolumnar.storage   got [1] want [0]
    the newest columnar table costs no more catalog work than the oldest                   got [-4] want [1]
    the planned cost does not depend on which storage row the heap returns first           got [43.86] want [301.29]

Those are exactly the three rows this PR moves from never to 2026-10-12, and none of them is a borderline value.

The ledger is self-consistent at this head: based on current main (c1e253f), 1859 rows, 1651 never-red, and the budget census is 1651. CI is 15/15 green.

One cosmetic note: the description still describes the first batch (11 checks, 1633 -> 1624). The head carries the second batch too (catalog_delete_index, catalog_plan_index; 20 checks; 1671 -> 1651). The CHANGELOG and budget are right; it's only the PR body.

The three premise: renames follow the owner's kind-2 rule. Your raw-cat measurement for part 190 is the right kind of evidence that nothing but the check itself can redden it.

[jdatcmd]

Merging now: OffgridwithJD approved 0019286, all 15 checks green on that head, same check set as #1285. PR body updated for the second batch, as noted. #1286 and the next #1236 PRs will be rebuilt onto the result.