refactor: columnar_reader gets its own header, the second of six (#496)

[ChronicallyJD]

Second of six for #496. The 12 declarations defined in columnar_reader.c with exactly one consumer outside it — the fold entry points, the liveness cache, the projection and filtered-read calls — consumed only by customscan, tableam and vector.

Gate

major	warnings + errors
pg15a	0
pg16a	0
pg17a	0
pg18a	0
pg19a	0

make clean between each (#536). native_vecdecode 24/24, native_fold_skipguard 4/4, harness_selftest 54/54 on pg18a.

This is NOT independent of #546, and I said it was

I set out to make the six module PRs independent so none of them auto-closes when a sibling merges — the failure that closed #534 this morning. I measured the closest pair of declaration removals in columnar.h between this patch and #546's: 49 lines apart, comfortably outside git's 3-line context, and concluded they could both sit on main.

The gate applied both to one tree and refused:

error: patch failed: src/columnar_reader.c:14
error: patch failed: src/columnar_tableam.c:13
error: patch failed: src/columnar_vector.c:36

The collision is not in the header. Three files consume both modules — reader, tableam, vector — and both patches insert their #include immediately after #include "columnar.h", so they edit the same anchor line in the same three files. My arithmetic was right about the thing it measured and blind to the surface that actually collides, which is the second time today I have proved something adjacent to the question.

So: still based on main, deliberately

The two options were stack or rebase, and rebase is cheaper here.

Stacking is what auto-closed #534: its base branch was deleted when the parent merged, and a closed PR whose base is gone can be neither reopened nor retargeted. The conflict in this case is three adjacent include lines — whichever of #546 and this one lands second wants a rebase that is mechanical and takes a minute.

A minute of rebase beats a PR that closes itself. Merge them in either order; I will rebase whichever is second.

The same collision will recur for every remaining module that shares a consumer, so this is the standing arrangement for the series rather than a one-off.

I have not merged this and will not.

[ChronicallyJD]

Reviewed the same way as #546. Clean, no objection to the content. The
structural finding is shared with #546 and I have written it up in full there
rather than twice.

Verified

Every .c that gained #include "columnar_reader.h" uses symbols from it:

columnar_reader.c    15 of 15    columnar_customscan.c  8
columnar_tableam.c    4          columnar_vector.c      4

No include added that nothing uses.

The shared finding, in short

#546 and #547 are both single commits based on main, neither containing the
other, despite being titled "the first of six" and "the second of six".
Trial-merging them in sequence conflicts in three files:

src/columnar_reader.c   src/columnar_tableam.c   src/columnar_vector.c

Not columnar.h — the removed hunks there auto-merge. It is the #include
lines added at the same place in the consumers both PRs touch, so the conflicts
surface in .c files that look unrelated to a header split. With six planned,
every pair sharing a consumer collides the same way.

Full detail on #546.

Worth noting for the remaining four

columnar_customscan.c uses 8 of this header's 15 symbols, which is the largest
cross-file dependency I have seen in either split so far. If a later PR in the
chain moves customscan's own declarations, that is the pair most likely to
produce a conflict that is genuinely about the split rather than about include
placement, and it may be worth taking that one before the easier ones while the
chain is short.