Tests for the #155 encoding rewrites (carries the stack)

[jdatcmd]

@ChronicallyJD tests for #283, #284, #285 and #286, as asked.

I could not base this on perf/155-gorilla-batch because that branch lives on
your fork, so this branch carries your four commits unchanged plus one test
commit, and targets main. Merge it in place of #286, or cherry-pick the last
commit onto your stack, whichever you prefer. The four commits are untouched.

Five-major matrix with the stack plus this suite: ALL VERSIONS PASSED,
encode_invariants green on all five.

What it pins

PR	check
#285	every bit-pack width the encoder selects, round-tripped against a heap mirror
#286	Gorilla across float patterns, through the batched writer
#284	dictionary at, below and above DICT_MAX_DISTINCT
#283	the premise the build skip rests on

Every check compares against a heap mirror rather than a literal, and each section
carries a control asserting the encoding under test was actually chosen.

The #283 check is the one worth your attention

Your claim is that skipping the build cannot change output. The step I could not
follow was "the dictionary is viable" implying "FSST is never selected", since the
gate is bestLen > rawLen - rawLen / 4.

That step is directly testable, so the suite tests it: no vector selects FSST at
or below the distinct cap, across eight shapes on both sides of it, short and
long values. It holds, so the reasoning is sound.

The control comes first and matters more than the assertion: a high-cardinality
corpus that does select FSST, because "no FSST below the cap" is trivially true
on a suite that cannot observe FSST anywhere. My first pass at reviewing this had
exactly that flaw and I nearly reported a clean sweep as confirmation.

Two edges it does NOT cover, found by removal proofs failing to fail

This is the part worth checking, because both look covered and are not:

• The (width == 64) mask. Reverted to the naive (1 << width) - 1, the
  suite stayed green. The encoder never selects packing at that width: measured,
  the dictionary wins above ~32 bits when distinct values are few, and when they
  are many across a wide range nothing wins, because packing near full width saves
  nothing over raw.
• The ctz_in zero guard. Deleted, the suite stayed green. Gorilla encodes
  identical neighbours with a same-as-previous bit, so ctz_in is never reached
  with zero from SQL.

Both are correct to keep. Both are defensive code a suite cannot reach, and
covering them needs a C-level test. An earlier version of this file claimed to
cover the first and passed while the naive mask was in place, which is why the
comments now state the limit rather than the intent.

The packer check does have teeth: dropping the sub-byte offset from the field
span (nb) makes width 15 fail.

Still open from my review

Your ctz_in comment says x == 0 "keeps the old all-zeros answer"; the old loop
was undefined on zero rather than returning 0.

I have still not independently reproduced the performance numbers, and the offer
stands to measure them interleaved on the idle box the way #276 was done.

[jdatcmd]

Added the C-level half, so the two edges I reported as uncoverable are now
covered. Five-major matrix: ALL VERSIONS PASSED, encode_invariants green on
all five, now 11 checks.

columnar_debug_encoding_selftest calls the primitives directly and compares each
against a reference implementation of the algorithm it replaced. That checks
the promise these rewrites actually made, which a suite cannot: not that data
survives a round trip, but that the bytes are the ones the old code produced.

• bitpack at every width 1 to 64, at nine value counts so packing starts at
  every sub-byte offset, random values plus the in-width extremes
• bw_put across all widths in mixed order, so the carry between calls is
  exercised at each offset, comparing both the byte stream and the residual carry
• clz_in and ctz_in over four window sizes and the edges a hardware bit scan
  gets wrong, including zero, one, the top bit and all ones

Values come from splitmix64 with a fixed seed, so a failure is reproducible rather
than a story about a random run.

Both previously uncatchable defects are now caught:

naive (1 << width) - 1 mask
  FAIL bitpack width=64 n=2: bytes differ from reference

ctz_in zero guard removed
  FAIL and the self-test actually compared a meaningful number of cases: ran=none

The second is caught by the anti-vacuity control rather than by a comparison:
pg_rightmost_one_pos64 asserts on zero, so the backend dies before returning a
row. Which means the guard is load-bearing in an assert build after all, not
merely defensive.

One finding from the matrix that is worth your attention beyond this PR.
utils/tuplestore.h arrives transitively behind funcapi.h through PostgreSQL 18
and does not on 19. The build failed on 19 alone, with 15 through 18 green. It
is fixed here with an explicit include, but it is the same class as the shims in
columnar_compat.h, and worth knowing if you add a set-returning function
anywhere else.

Also worth recording because it nearly cost the work: my first attempt at these
proofs destroyed the self-test. git checkout src/columnar_encoding.c restores
from the index, the new code was never staged, so the proof wiped it and I
committed a test that could not run. The matrix caught it as ran=none on all
five majors, which is the control doing exactly what it was written for.