feat: decode honours the skip vector it already builds (#452 phase 1b-i)

[ChronicallyJD]

#452 phase 1b-i, specified in design/ISSUE_452_LATE_MATERIALIZATION.md.

What was wrong

Columnar Vectors Skipped never meant what its name suggests. Decode ran
before the skip vector existed:

:1598   pgcolumnar_native_decode_chunk(...)      per wanted column
:1615   pgcolumnar_native_build_skipvec(...)     from zone maps

So a vector the zone maps had ruled out was decoded in full, and the skip only
stopped it being turned into Datums. The counter said "not emitted", never "not
decoded", and no existing counter could tell those apart.

Nothing about that ordering was necessary. The vector count lives in the
encoding descriptor header, which is chunk metadata already in hand, and
build_skipvec's only other inputs are the predicates and the zone map catalog.
A metadata-only pre-pass reads the count and decides allDescriptor without
touching a value byte.

Two things this deliberately does not do

• It does nothing for ClickBench q24. A leading-wildcard LIKE yields
  numPredicates == 0 and a NULL skip vector. The ~3200 ms budget there is
  1b-ii, and none of the six Citus columnar loads the same data 3x faster than we do, which contradicts why #300 was closed #445 losses is helped by this. It pays on queries
  with a usable predicate, which is most analytic filters.
• It does not avoid decompression. The block codec still reverses the whole
  chunk; that is cost 1 and needs a format change (Phase 2). This removes cost 2,
  the per-vector decode.

The fold had to change too, and #523's tripwire is why I knew

Skipping decode leaves holes in the packed value stream. The row producer is
safe (it steps its cursors past skipped vectors); the fold is not, because it
reads that buffer directly and re-checks every value. #523 landed a guard for
exactly this ordering, and it fired on the first run:

ERROR: pgcolumnar: the vectorized aggregate cannot fold a row group whose
decode skipped vectors (#512); teach this loop to honour the skip vector in the
same change that makes decode honour it

That guard did its job. The fold now walks the per-vector map it was already
handed, and skipping there is exact rather than merely safe:
pgcolumnar_batch_shape_eligible requires every qual to be convertible to a scan
key, and those keys are what the reader built the skip vector from. The present
index still advances across a skipped vector, as it does across a deleted row,
because the stream is packed by presence.

The part worth reviewing: two instruments that could not see their subject

The counter was unfalsifiable. I first derived "vectors decoded" from the
mask the caller passed in. It reported the saving whether or not decode honoured
the mask, and the removal proof passed with the fix removed. It is now
reported from the loop that does the work.

The correctness checks could not see the hazard. Reading a hole is undefined
behaviour whose symptom is data-dependent: whatever palloc last left there is
normally rejected by the fold's own scan-key recheck, so a fold that reads every
hole returns the right answer on ordinary data. Measured, not reasoned about:
with the skip removed from the fold, all 20 checks passed.

So assert builds now poison a skipped vector's bytes with 0xA5, which as an
int4 is -1515870811, and the suite adds a predicate chosen to accept that
value while still letting the zone maps rule most vectors out. With the fold's
skip removed, that check reports 32,696 rows where heap says 3,000.

Proof

test/native_vecdecode.sh, 23 checks. Every premise is asserted first, so a
plan change or a split row group cannot masquerade as a decode regression.

Proved by removal, three ways:

removal	what catches it
decode ignores the mask	decoded + skipped == the group's vectors
a HALF-working mask, skipping only the first ruled-out vector	the same check; decodes fewer still passes, which is why the check is an equality and not an inequality
the fold ignores the mask	only the poison check
the present index does not advance over a skipped vector	the deep-range fold check returns 0 rows; the shallow one merely returns a wrong count, which is why the deep range is there

Gate

• PG17 assert: 131 ran, 5 skipped, all pass.
• PG19 assert: 136 ran, one failure: temporal. That is btree_gist missing
  in my container, it fails identically on unmodified main, A suite that ran no checks must stop reporting PASSED (#447) #448 made a
  missing dependency a failure by design, and PGC_ALLOW_MISSING_BTREE_GIST=1 is
  its documented override. Not this change.

Refs #452, #512