The ledger key omits the PostgreSQL major, so a check that exists on only some majors cannot be represented -- and orphan-scan will call it deleted

[OffgridwithJD]

#982 found that (suite, name) was a key of check NAMES rather than of checks, because
harness_selftest sources 40-odd parts into one shell and phrases its premises to be
copied. The fix added the part. This is the same defect one field further out: the key
omits the PostgreSQL major, and a check's existence depends on it.

The key cannot represent what the tree actually emits

Two shapes, both on main at 4d7c75ae, both verified by reading the suite.

1. A whole suite collapses to one record on the older majors.
test/analyze_differential.sh:61:

if [ "$PGC_MAJOR" -lt 18 ]; then
	check_skip "the differential analyze path" "SKIP  pgcolumnar.analyze() needs pg_restore_attribute_stats (PG18+); this server is $PGC_MAJOR" "..."
	pgc_summary
fi

pgc_summary exits. So this suite emits 1 record on PG15-17 and N on PG18+. Same for
test/analyze_function.sh:70.

2. The two branches emit DIFFERENT CHECK NAMES, so the key sets are disjoint.
test/fk_referencing.sh:287:

if [ "$PGC_MAJOR" -ge 17 ]; then
	check "a partitioned table with no foreign key still converts" ...
	check "and its partitions inherit the columnar access method" ...
else
	check "before 17, core refuses this for every partitioned table" ...

On PG17+ the ledger sees two names; on PG15-16 it sees a third that cannot appear on
PG17+. Nothing in the key says which majors each belongs to, so the ledger cannot hold
"this check exists on 17+ and not below" -- it can only hold "this check exists".

A grep for PGC_MAJOR does not find all of these, which is why the fix needs the
dimension rather than a convention. test/native_repack.sh:48, test/pg19_vacuum_options.sh:34
and test/native_dml.sh:61 gate on server_version_num instead and never mention
PGC_MAJOR. Any rule phrased over one idiom misses the other.

What it costs today, stated precisely

Nothing, yet, and that is the point. All 1,155 committed rows come from three suites,
and I checked each for version gating:

suite	rows	version gates
harness_selftest	907	0 -- never references PGC_MAJOR at all
differential	204	0
native_join_runtime_filter	44	0

So this is not a live defect in the committed ledger. It is a blocker on seeding the
suites that do diverge, and every one of those is currently among the 249 uncovered:
analyze_differential, analyze_function, fk_referencing, unique_conc,
native_repack, pg19_vacuum_options, native_dml.

The direction that breaks first is orphan-scan, not gate

gate refuses a check in the log that the ledger has not seen. A PG18-only check simply
does not appear in a PG15 log, so the gate stays correct by never being asked.

orphan-scan asks the opposite question -- a ledger row no record in its own part matches
-- and that is exactly what a PG18-only row looks like in a PG15 run. It is saved today
only by the skip guard:

skipped_parts = {(s, p) for (s, p, _), v in verdicts.items() if "SKIP" in v}
orphans = [k for k in absent if (k[0], k[1]) not in skipped_parts]

analyze_differential on PG15 emits a check_skip, so its part lands in skipped_parts
and its absent rows are classified unprunable rather than orphans. That is luck, not
design: fk_referencing's older-major branch emits check, not check_skip, so once
that suite is seeded, a PG15 run reports its two PG17+ checks as orphans -- rows naming
checks that have been deleted, when they have not.

The fix, and the one thing it cannot honestly do

Put the major in the key: (major, suite, part, name).

Two costs, both real:

1. The census changes meaning. checks_never_observed_red would count (check, major)
   pairs, not checks -- roughly 1,155 -> ~5,800 at today's coverage. 5800 under a name
   that says "checks" is a number that lies by its own name, so the budget file has to
   restate it and the gate should print pairs and distinct checks side by side. It already
   prints two quantities, so that part is cheap.

2. The 1,155 existing rows cannot be given a major. Their last_red and mutations
   were observed on some major and nothing recorded which. Regenerating loses the attack
   history, which is the ledger's whole value; copying one observation into five majors
   claims five observations from one. So they carry an explicit "no major recorded"
   sentinel, and that is a true statement rather than a migration stopgap -- harness_selftest
   never reads PGC_MAJOR, so 907 of them have no major to record even in principle.

That second point is worth stating plainly, because it is the part that surprised me: the
row's two columns are not the same kind of thing. Existence is per-(check, major) and
cheap to re-derive from any run. History is per-check and cannot be re-derived at all.

Prerequisite: the log must name its own major

RESULT records carry suite, part, name, verdict, reason and no major, so the tool can
only learn the major from whoever invokes it. That is the --date not-a-date failure
waiting to happen: a PG15 log merged as PG18 is silently misattributed, and the ledger's
subject is provenance. The record should carry the major and the runner should still pass
the one it ran, so the two reconcile -- the same fail-closed shape read_records
already applies to checks run:.

That splits cleanly and in dependency order:

• Step 1. The record names its major; the tool validates it and ignores it. Green on
  its own, independently useful (a log becomes self-describing), no ledger change.
• Step 2. The ledger keys on it: format, migration to the sentinel, every subcommand
  widened, budget restated.

[OffgridwithJD]

Measured on a full matrix, and it changes the recommendation

Two full matrices at 4d7c75ae, PG15 and PG18, ALL VERSIONS PASSED on both. 252 suite
logs each. The key sets:

pg15 keys        6372
pg18 keys        6467
on both          6367
pg15 only           5
pg18 only         100
union            6472
major-specific    105   (1.62%)

Nine suites differ. One of them is not a version difference at all, and excluding it is the
first thing to say:

fuzz contributed 500 of the raw 605 differences and none of them are about the major.
Its check name interpolates the random fixture, so every run emits 250 brand-new keys --
shared: 0 between the two majors, and shared: 0 between two runs on the same major with
the same seed. That is a separate bug, filed as #1011 (PGC_SEED does not seed anything,
because every generator call is a command substitution and bash re-seeds RANDOM in a
subshell). Every number above excludes fuzz.

The eight suites that genuinely diverge:

suite                    pg15only pg18only   shared
analyze_differential            1       26        0
analyze_function                1       54        0
audit                           1        4       27
column_projection               1        1       37
fk_referencing                  1        2       24
generated_columns               0        6        5
native_sort_by                  0        2       16
temporal                        0        5        0

analyze_differential and analyze_function have zero shared keys: the one PG15 record
is the check_skip, and the PG18 records are the suite. That is the shape the issue
predicted, confirmed.

The cost of (major, suite, part, name), with the real denominator

At full coverage the ledger holds ~6,472 rows. Putting the major in the key multiplies all of
them:

6472 x 5 majors = 32,360 rows, to express 105 keys' worth of major-specific information
                  ~247 extra rows per row that actually differs

6,367 of 6,472 checks are identical on both majors. Storing them five times stores one fact
five times, and a-repeated-measurement-must-be-idempotent is the lesson about exactly that.

I am building it as decided -- this is the cost, not an objection, and the decision to
pay it is reasonable: a key that cannot represent what the tree emits is wrong regardless of
how often it matters today, and 1.62% is not zero.

But the measurement does suggest a variant worth one sentence of consideration, because it is
the same key with the same guarantee at 1:1 rather than 5:1. Let the major field hold a SET:
* for a check observed on every major the ledger has seen, and an explicit list otherwise.
6,472 rows stay 6,472; the ~105 divergent ones carry 15 or 18+. It is still the major in
the key -- orphan-scan gets the scoping it needs and fk_referencing's PG17+ checks stop
reading as deleted -- without 26,000 duplicate rows. The cost is that * must mean "every
major this ledger has observed" and the ledger must record which those are, or a new major
silently inherits a claim nobody measured.

Say which you want and I will carry on with that one. Step 1 below does not depend on the
answer.

Step 1 is done and in verification

The record now names its major: RESULT<TAB>suite<TAB>part<TAB>name<TAB>verdict<TAB>major<TAB>reason.
Validated rather than stored -- eighteen, 18.2, pg18 and an empty field are each
refused -- and unknown is accepted as lib.sh's own word for a field the harness did not
set, which harness_selftest needs because it never references PGC_MAJOR.

The ledger is untouched in step 1: it still keys on (suite, part, name) and discards the
major, so it is green on its own and carries no migration.