[OffgridwithJD]

@jdatcmd The next twin-less suite, stacked on #1496 (#1489 → #1493 → #1496 → this). This PR's own commits are the top two.

Two arms couldn't see the faults they name

• "pyarrow uuid reads as uuid" read ORDER BY u LIMIT 1, the all-zero uuid, which every byte order leaves unchanged. With the reader reversing a uuid's bytes, the old arm stayed green. It now reads both values in order, and that mutant is red in both twins.
• "crafted out-of-range scale is rejected, not decoded" counted any error as REJECTED. Removing the bind guard (pq_decimal_bounds_ok in pq_want_phys_for) left it green: the decoder's own scale > 38 check refused the file instead, as XX001 could not decode Parquet column 0, after decoding had begun. The bind refuses with 42804, and the arm now requires REJECTED 42804 (the shell's pgc_try_flba returns the SQLSTATE). With the guard removed it's red in both twins.

The twin, name for name

All 15 checks by the shell's name, in three tests. Under each mutation, the twin reddens exactly the shell's set:

mutation (columnar_parquet_reader.c)	reds, shell = twin
uuid bytes reversed	5: four round trips and the pyarrow uuid
a narrow negative DECIMAL read unsigned	3
bind guard dropped	1
bind guard and decoder scale check dropped	1
integer DECIMAL widened byte-reversed	2
parquet_schema advises integer for INT32 DECIMAL	1
bigint scaled like numeric	1

Five-major runs at head: 15/15 for the shell and 15/15 for the twin, on each of 15–19.

Ledger

Census 4278 / 3006 never / 1272 dated (on #1496's 4263 / 3002 / 1261), with suites_not_covered 196 → 195. 11 of the 15 checks are dated. The gate gives rc 0, and orphan-scan finds 0. 4 arrive never:

• the round-trip numeric arm: our export writes 16-byte DECIMALs, which are decoded by bit pattern, so the narrow-width sign mutation doesn't reach them;
• the INT32 null;
• the INT64 schema advice;
• backend liveness after the crafted scale.

Collection gives cluster_tests 734 -> 737, and TESTS.md gets §170. The grader is 15/15 by name, and the guards pass 438/438.

🤖 Generated with Claude Code

[jdatcmd]

Approve, at 9502a8a (its own commits 6608a71 and 9502a8a, on #1496).

My own mutant, different from your seven: the uuid decode zeroes the last byte after the copy (u->data[UUID_LEN - 1] = 0), not a reversal. PG17 shell, 5 red:

• the three round trips and the FDW scan (md5 mismatch);
• "pyarrow uuid reads as uuid": got [00000000-…-000000000000,11111111-2222-3333-4444-555555555500] want [...,…555555555555].

The old form of that arm read only the all-zero uuid, which this mutant also leaves unchanged. So your strengthened arm is what catches it, not the round trips alone.

What I could not verify: as on #1496, I can't run the pytest twin here: /root/pyenv has no pyarrow, so it declines. Twin parity rests on your measurement and CI.

[jdatcmd]

@OffgridwithJD, merging #1497 now: approved at 9502a8a, 15/15 green, CLEAN.