Test coverage: on-disk (PGCN v1) and extension-version compatibility across builds

[ChronicallyJD]

Gap

Nothing tests that a columnar table written by one build of the extension is readable by a later build, and there is no CREATE / ALTER EXTENSION UPDATE / downgrade / DROP EXTENSION round-trip test. Only pgcolumnar--1.0.sql exists (fine at a single version), but the on-disk format (PGCN v1) has no automated compatibility guard across builds, and the on-disk encoding descriptor is host-endian (columnar.h:56).

Why this blocks a public release

Alpha data that a later version silently cannot read is a data-loss trap. Users need either a tested format-stability guarantee or an explicit "no format stability yet, reload from source across upgrades" notice backed by a test that the current format at least round-trips within a version.

Suggested acceptance criteria

• A suite that writes a table with an older extension build/format and reads it with the current build, asserting identical query results (or a clean, documented rejection with a version error rather than a crash or wrong answer).
• An ALTER EXTENSION pgcolumnar UPDATE path test once a second version script exists.
• Document the format-stability policy (stable vs reload-required) in docs/limitations.md.

Found in a release-readiness review; sibling of the pg_upgrade and physical-replication coverage issues.

[ChronicallyJD]

Capturing two Phase-1 items for #240 so they aren't lost once #270 (Phase 0) lands. Neither is a live data-safety hole today -- the metapage version guard covers every path -- they matter only in the scenario Phase 0's format_version enforcement is for: a data-encoding change (PGCN v2) that leaves the physical metapage layout unchanged.

1. Upgrade path + golden fixture. Once a v2 format exists: an ALTER EXTENSION UPDATE-style path across an incompatible bump, and a golden on-disk fixture proving an old file still reads (or is rejected cleanly). Per jdatcmd's caution, pin the fixture to an uncompressed codec so a zstd/lz4 library-version change doesn't fail it for reasons unrelated to the format.

2. Write/modify paths on an unsupported format. Phase 0 guards the read/decode paths (scan open, zone-map aggregate, by-row-number fetch) so a future format is refused rather than misread. But paths that modify without decoding currently complete on a future-format table:

• DELETE marks rows in the delete vector without decoding column values (observed returning success in jdatcmd's probe against 47a6f55).
• pgcolumnar.vacuum / compaction reads through ColumnarBeginRead, so it is refused today -- but whether a rewrite path can ever rewrite bytes it refuses to read was not exercised (the probe fixture didn't trigger compaction: compact was 6 row groups -> 6 even on a healthy table).

The open decision for Phase 1: should a build refuse to rewrite or modify a table whose format it cannot read, not just refuse to read it? Refusing is the safer posture; the counter-argument is that a delete/vacuum that never decodes column bytes cannot corrupt them.