Add TAP coverage for corrupt WAL summary and backup manifest files

[NikolayS]

What

Two new deterministic, mutation-based TAP tests that prove the "corrupt file in, clean error out" contract: generate a real input file, apply fixed-offset / fixed-value mutations (no randomness), run the consuming tool on each mutant, and assert it exits nonzero with a clean error message and is never killed by a signal (crash / assertion failure / core dump).

• src/bin/pg_walsummary/t/003_corrupt.pl
• src/bin/pg_verifybackup/t/011_manifest_mutation.pl
• registered both in the respective meson.build

Why

Commit ee654419d5 ("Add additional sanity checks when reading a blkreftable") hardened src/common/blkreftable.c with fork-number and chunk-size validation after external fuzzing found that a corrupted file could index off the end of the fork-number or chunk-entry arrays and crash. No regression test exercised that path, so nothing guards those checks (or the surrounding truncation / overflow handling) against regressing. The mutations here target exactly the fields ee654419d5 validates (fork numbers, chunk sizes) plus the structural boundaries it does not (magic, CRC, EOF, plausible-but-too-large counts).

Note: command_fails_like() only checks nonzero exit + stderr — a signal death still counts as "fails". These tests capture $? directly and assert the low 7 bits (signal) are zero, so a crash is caught as a distinct failure.

Existing vs. added coverage

pg_walsummary — previously only 001_basic.pl (help/version/usage) and 002_blocks.pl (happy-path parsing of a valid summary). No corrupt-input coverage existed. 003_corrupt.pl is entirely new.

Mutation matrix (parses the real file's on-disk layout, then mutates precise offsets):

Category	Mutation	Expected clean error
Truncation	0 bytes, mid-magic (2B), after-magic (4B), mid-header, mid-chunk, mid-CRC	ends unexpectedly
Bit flip	corrupt magic	wrong magic number
Bit flip	fork number too large (16) / negative (-5)	invalid fork number
Bit flip	corrupt limit_block (valid → CRC catches)	wrong checksum
Field	oversized chunk-size value (0xFFFF > 4096)	chunk N has invalid size
Count	oversized nchunks (0xFFFFFFFF)	oversized chunk size array
Count	large-but-plausible nchunks (reads off EOF)	ends unexpectedly

pg_verifybackup — 005_bad_manifest.pl already feeds hand-written tiny manifests to hit individual JSON parse / checksum / size errors, and 003_corruption.pl appends one byte to a real manifest (→ checksum mismatch) and swaps manifests. What was missing: truncating and bit-flipping a real, full-sized manifest at the byte level. 011_manifest_mutation.pl adds only those missing shapes:

Category	Mutation	Expected clean error
Truncation	0 bytes, 1 byte, midpoint, drop final newline	parse error / checksum mismatch
Structural bit flip	top-level {→[, corrupt version key, corrupt file-object start	could not parse backup manifest
Bogus field	flip a file Size digit, flip a file Checksum hex char, flip a Manifest-Checksum hex char	manifest checksum mismatch

Test evidence

Built with meson setup build --buildtype=debug -Dcassert=true -Dtap_tests=enabled (asserts on, so an out-of-bounds access would trap as SIGABRT).

pg_walsummary / 003_corrupt                OK   41 subtests passed
pg_verifybackup / 011_manifest_mutation    OK   32 subtests passed

Neighbours confirmed still green: pg_walsummary/001_basic, 002_blocks, pg_verifybackup/005_bad_manifest.

No mutation produced a crash or signal exit — every corrupt input was rejected cleanly, confirming the reader/parser hardening holds. No live bug found.

Closes #70

🤖 Generated with Claude Code

https://claude.ai/code/session_01PtxA6B4d47ietk5dGsseuP

---

Generated by Claude Code