Document five settings and correct two false claims (1.0-alpha docs pass)

[ChronicallyJD]

What

The docs accuracy pass from #367. Two separate problems: settings that exist and are
not documented, and documented claims that are not true.

Every registered GUC is now documented

Five were missing from docs/configuration.md. Four are user-facing and land in
Scan and execution:

• pgcolumnar.enable_ungrouped_vector_agg
• pgcolumnar.enable_parallel_vector_agg
• pgcolumnar.enable_column_projection
• pgcolumnar.enable_index_fetch_penalty

The fifth, pgcolumnar.bulk_parallel_writer, is internal — set by
pgcolumnar.parallel_copy workers and marked GUC_NOT_IN_SAMPLE. It gets its own
short Internal settings section rather than a row among the tuning knobs, because
it appears in pg_settings and a reader who finds it there deserves an answer rather
than silence.

Checked mechanically rather than by eye:

$ comm -23 <registered GUCs> <GUCs named in configuration.md>
(empty)

Two claims in limitations.md are wrong

"ANALYZE samples the rows through the fetch path and not by block." It does not.
columnar_scan_analyze_next_tuple reads with a reader restricted to one row group.
Measured with an instrumented build (an elog at the top of columnar_fetch_row,
PG18 assert, statement-marked log):

fetch_row calls during ANALYZE:              0
fetch_row calls during control point query:  2

The control is an indexed point query on the same table, so the probe is live and the
zero is real. The sentence is replaced with what is true and still explains the cost:
the sampler offers every row of every block it visits, so the cost follows rows
offered rather than rows kept.

"The cost therefore no longer increases with the width of the table." It does, in
two ways that are easy to meet at once, and this is the sharp edge jdatcmd asked to
have documented rather than left silent (#367):

• an index fetch decodes the attribute prefix up to the highest-numbered column the
  query reads, not the columns it reads (The index-fetch cost model sizes the decode from the emitted columns, but the fetch decodes the attribute prefix: 200x invisible to reltarget->width #363);
• columns that exceed the fetch cache's size limit are decoded again on every fetch
  (The fetch cache cliff persists after #357: 4 to 5 aggregate columns is a 47x jump #359, and the bound correction in #361's fetch cache is not bounded by 4x the cap: one entry measures 62 MB against 32 MB on a wide varlena table, and gets 1.14x #364).

Measured on ten text columns, same rows and same plan: 975 ms on the first
column against 194,798 ms on the tenth.

Note this is documented as current behaviour. #368 fixes the cost model so the
planner stops walking into it, which is a different thing from the fetch itself
becoming cheap — the fetch still decodes the prefix.

Style

test/ste_check.py passes on every user-facing document, which is what
docs_style.sh gates on. The measured sentences needed splitting to stay inside the
25-word STE limit; that is a real constraint on how these paragraphs read and I have
kept the numbers rather than the prose where they conflicted.

🤖 Generated with Claude Code

[jdatcmd]

Approved

Docs-only, CI green (which runs docs_style over docs/*.md in full), and it
fixes the two things that actually mattered for an alpha.

The limitations.md correction is the important half. The old text said a fetch
"decodes only the columns that the executor asks for", which #363 disproves: it
decodes the prefix up to the highest-numbered column referenced. That sentence was
not vague, it was wrong, and it was the sentence a user would have relied on when
laying out a wide table. Replacing it with both causes and the 975 ms / 194,798 ms
measurement is the right level of specificity.

Documenting enable_column_projection and enable_index_fetch_penalty closes a
real gap, since both are on by default. #372 covers the same two in the changelog,
so a reader arriving from either direction now finds them.

The bulk_parallel_writer entry is a good call. A GUC_NOT_IN_SAMPLE setting still
shows up in pg_settings, and "leave it alone" plus the reason it is safe to touch
is more useful than omitting it and letting someone guess.

One trivial note, not worth a round trip: the enable_index_fetch_penalty row says
"restore the pre-1.0-alpha planner behaviour" while VERSION still reads 1.0-dev
and nothing is cut yet. It reads fine once the alpha lands, which it will before
this text is user-visible. I will make sure the version cut does not contradict it.

Merging.