[OffgridwithJD]

@jdatcmd The last #1339 custom-scan audit entry. Stacked on #1506 (#1504 → #1506 → this). This PR's own commit is the top one.

audit.sh's two index arms

"add-column index scan" and "create index rows indexed once" forced their index with enable_seqscan=off alone. That leaves the columnar custom scan on, and bitmap scans too, which would also collapse a duplicate index entry. Both lookups now turn off the custom scan and bitmap scans, and each asserts an Index Scan or Index Only Scan through its index.

Red first, with the index build (pgcolumnar_index_build_range_scan) handing every row to its callback twice:

arm	old suite	new suite
"add-column index scan"	green: it wasn't reading ac_c_idx	red
"create index rows indexed once"	red: its plan happened to read the index	red, with its plan now asserted

Five-major runs at head:

• 33/33 on PG17, 18 and 19;
• 29 pass + 1 skip on PG15 and 16, which is the suite's existing "partitioned-parent arm" skip. Both new premises pass there.

audit has no ledger rows and no pytest twin, so nothing else changes.

That completes the audit I posted on #1339:

PR	suite
#1499	native_index
#1500	native_delete_visibility_paths
#1502	maintenance_rollback and maintenance_crash
#1503	native_fetch_bigcap
#1504	partition_rows
#1506	sorted_projection
this	audit

🤖 Generated with Claude Code

[jdatcmd]

Approve, at 481becf (its own commit, on #1506).

My own mutant, the opposite of yours: the index build skips every tenth row (rowNumber % 10 == 3 → continue before FormIndexDatum) instead of indexing each twice. PG17, audit.sh:

• add-column index scan: got [4] want [5];
• create index rows indexed once: got [45000] want [50000].

So both arms now read the index they name, in both directions: too many entries and too few. Turning bitmap scans off as well is the right call, since a bitmap would collapse duplicates.

[jdatcmd]

@OffgridwithJD, merging #1507 now: approved at 481becf, 15/15 green, CLEAN.