21 suites report PASSED with zero checks when pyarrow is missing, so the whole Arrow and Parquet surface can leave the gate silently

[ChronicallyJD]

What happened

I set out to verify #446 by running the Parquet suites myself. They all reported PASSED. Then
I looked at the check counts:

  native_parquet_pushdown             0 checks  PASSED
  native_parquet_projection           0 checks  PASSED
  native_parquet_multifile            0 checks  PASSED
  native_parquet_partition            0 checks  PASSED
  native_parquet_streaming            0 checks  PASSED
  native_parquet_codecs               0 checks  PASSED
  native_parquet_hardening            0 checks  PASSED
  fuzz_parquet                        0 checks  PASSED

The bench had no pyarrow. Each of those suites does this and stops:

echo "SKIP  pyarrow not available; Parquet hardening suite needs it"
pgc_summary
exit 0

exit 0 is a pass. After apt-get install python3-pyarrow on the same tree and the same
build, the same ten suites ran 190 checks. Nothing about the code changed between the two
runs. Only the dependency did.

Why this matters more than it looks

21 suites gate on pyarrow, which is the entire Arrow and Parquet surface:

arrow_export arrow_import arrow_nested fuzz_arrow fuzz_parquet
native_parquet_codecs native_parquet_flba native_parquet_hardening
native_parquet_multifile native_parquet_partition native_parquet_projection
native_parquet_pushdown native_parquet_schema native_parquet_streaming
native_parquet_units parquet_export parquet_import parquet_nested
parquet_nested_import native_read_parquet native_parquet_fdw

On a machine without pyarrow, run_all_versions.sh runs them, gets exit 0 from every one,
and reports the run green. The output says PASSED next to each. There is no aggregate line
that says 21 of 123 suites tested nothing.

That includes both Parquet fuzzers. The suites most likely to catch a decode bug on
attacker-influenced bytes are the ones that vanish most quietly, because their skip looks
exactly like their pass.

This is the same defect class we already fixed once

#422 fixed run_all_versions.sh reporting ALL VERSIONS PASSED when five of six versions
were skipped, because the default prefixes did not match the machine. The fix was a
VERSIONS_RUN counter, NO VERSIONS RAN at zero, and VERSIONS RUN PASSED (n of m)
otherwise. This is the identical shape one level down: a skipped unit reporting the same
verdict as a passed one.

Suggested fix, matching what #422 did

1. A suite that ran zero checks should not print PASSED. pgc_summary already knows the
   count, so it can print SKIPPED (0 checks) and exit with a distinct status.
2. run_all_versions.sh should count skipped suites and report n of m suites ran, failing
   if that is below a floor, the same way it now fails at zero versions.
3. Optionally, a PGC_REQUIRE_PYARROW=1 for gate runs, so a gate treats the missing
   dependency as an error while a developer laptop keeps the graceful skip.

I am happy to write this if nobody else has it.

Scope note on my own past gate runs

Every gate I ran on the bench before today reported the Parquet and Arrow suites green
without executing them. I do not know yet how far back that goes, and I am not claiming any
specific merged PR is affected. I am flagging it because the same is true of anyone else's
runs on a box without pyarrow, and because it changes what "the suites are green" is worth
until item 1 above exists.

[ChronicallyJD]

Correcting my own numbers, and why the fix I proposed would have broken the gate

I audited every zero-check path in test/ before writing this. Two things I got wrong above,
and one thing that would have turned the matrix red on the majority of majors.

My "21 suites" is wrong. The number is 15.

21 is how many files mention pyarrow. Only 15 reach pgc_summary with zero checks:

arrow_export arrow_nested parquet_export parquet_import parquet_nested
fuzz_arrow fuzz_parquet native_parquet_codecs native_parquet_hardening
native_parquet_multifile native_parquet_partition native_parquet_projection
native_parquet_pushdown native_parquet_streaming native_parquet_units

The other six are better than I said. arrow_import, native_parquet_flba,
native_parquet_schema and parquet_nested_import set a have_pyarrow flag and skip only a
section, keeping their top-level checks. native_parquet_stack and parallel_export_parquet
only mention pyarrow in a comment ruling it out.

That distinction matters for how the fix is described: it closes the zero-check gap, not
the pyarrow gap. Those four partial suites still lose real coverage silently when pyarrow is
missing, and a zero-check rule will report them fully green. That is a separate problem.

Also worth noting fuzz_arrow:41 and fuzz_parquet:43 have no literal exit 0. They exit 0
through pgc_summary's own exit $PGC_FAIL, so grepping for exit 0 misses them.

Item 1 as I wrote it would red 3 of 5 majors on the first run

I proposed "a suite that ran zero checks should not print PASSED". Applied literally that
breaks legitimate configurations:

suite	zero checks when	blast radius
temporal.sh:26	major < 18, WITHOUT OVERLAPS does not exist	PG15/16/17, including the per-PR suites (PG 17) gate
temporal.sh:32	btree_gist not installable	any box without that contrib
isolation.sh:40	no pg_isolation_regress, and PGC_REQUIRE_ISOLATION unset	every local run on a packaged server-dev
native_parquet_streaming.sh:61	the 1600MB sparse fixture cannot be built	low-space boxes

There is nothing to test and nothing to fix in the temporal case. Making it red is exactly the
"a red everyone knows to ignore is a red nobody reads" failure this tree keeps arguing against.

So the verdict has to be a third state, not FAILED. Skipped and failed are different
properties, the same way #422 needed "ran" separate from "passed".

isolation.sh already has the pattern: a soft skip by default, made fatal by
PGC_REQUIRE_ISOLATION=1, which CI sets at ci.yml:448. The pyarrow suites should get the
same escape hatch rather than a new one.

Two suites a fix inside pgc_summary will not reach

pg19_vacuum_options.sh:34 and native_repack.sh:48 print their own SKIPPED line and
exit 0 without calling pgc_summary. They will keep reporting PASS with zero checks on
PG15 through PG18 whatever pgc_summary does. If the fix lands and is declared complete on the
strength of the pyarrow suites, that hole ships with it.

And a runner-side log rule is worse than the disease

smoke, phase2 through phase6, audit, concurrency and unique_conc do not use
pgc_summary and never print checks run: at all, while running many real checks. Any rule
that greps the log for a count marks all nine as zero-check on every major: 45 false reds on a
five-major run. Separately, the PGC_SKIP_TIMING synthetic pass at run_all_versions.sh:435
writes an .rc and no log at all, so a log rule reds the three timing suites in exactly the
CI configuration that is supposed to keep them quiet.

The count has to travel by exit status, not by log text.

What I propose to write instead

1. pgc_summary reports SKIPPED and exits 2 when PGC_CHECKS is 0 and PGC_FAIL is 0.
   Not FAILED. Exit 1 keeps meaning a real failure.
2. Teach the four consumers that 2 is a skip rather than a pass: run_all_versions.sh:448,
   run_san.sh:95, run_coverage.sh:84, devloop.sh:69. Today all four treat any non-zero as
   FAIL, so this cannot be done in lib.sh alone.
3. run_all_versions.sh reports n of m suites ran, and fails at zero, mirroring the
   VERSIONS_RUN shape from Refuse to compare a measurement nobody took (#418) #422 one level down.
4. PGC_REQUIRE_PYARROW=1 makes the skip fatal, matching PGC_REQUIRE_ISOLATION. Whether CI
   sets it is a policy call and I am not making it in the patch.
5. Convert pg19_vacuum_options.sh and native_repack.sh to the same path so the invariant is
   actually tree-wide.

Two implementation traps I will avoid, noted here so they are on the record: an EXIT-trap
approach is silently dropped by logical_subscriber.sh:65, replication.sh:162 and
harness_selftest.sh:93, all of which replace pgc_teardown; and any new test/*.sh file must
be registered in SUITES or harness_selftest.sh's allowlist or the selftest reds.

Taking this unless someone objects.