Record the alpha3 bug-sweep fixes in the changelog

[OffgridwithJD]

Documentation only. Six defects were found and fixed today and none of them reached
CHANGELOG.md.

Why it matters for three of the six

I checked each against the v1.0-alpha2 tag rather than applying a rule, because the
answer is not the same for all of them:

issue	fix	present at v1.0-alpha2?	how I checked
#838	#839	yes	the ActiveSnapshotSet() ? GetActiveSnapshot() : GetTransactionSnapshot() line and the knowndeletable assignment are both in git show v1.0-alpha2:src/columnar_tableam.c
#842	#843	yes	pgcolumnar_scan_getnextslot exists at the tag with exactly one reference to direction: the parameter
#844	#845	yes	ice_has_encoded_dotdot and ice_percent_decode_once exist at the tag, the NUL check does not, and iceberg_scan is in the shipped pgcolumnar--1.0-alpha2.sql
#834	#835	no	Anum_options_ttl_* arrived in bb97a86, after the tag, so Natts_options 7 was correct then
#836	#837	no	pgcolumnar_preimage_range_scankey does not exist at the tag
#840	#841	no	i128sum does not exist at the tag

So a user on v1.0-alpha2 today has three of these, and until now could not learn
that from the file written for exactly that purpose. count(*) answering 228 where
the truth is 400 is the sort of thing someone needs to be able to find.

What the entries do

Each one states whether a released version is affected, because that is the part a
reader acts on and it is not uniform across the six. For the three that are cycle
only, saying so is useful rather than pedantic: an entry that does not distinguish
them invites someone to go looking for a release that was never affected.

Each also carries the measurement that established the defect, in the form the issue
recorded it, so the entry can be checked rather than believed: 228 of 400 reachable
through the index, 6 7 8 where the heap gave 4 3 2, 58P01 meaning the escaped
path was fetched rather than refused, and the three growing sums across four LATERAL
iterations.

They are ordered by whether a released version is affected rather than by issue
number, because that is the question a changelog is opened to answer.

Gate

arm	result
preflight PG 15/16/17/18/19	built 5 of 5, 0 warnings
matrix PG18	234 ran, 2 skipped, ALL PASSED
matrix PG19	236 ran, 0 skipped, ALL PASSED
docs_style	PASS on both arms, 9 of 9
failing suites	none

Run at 2e5b1f04 against main a45b4cf2, so the tallies already include the
suites the six merges added.

docs_style is the only suite in the tree that reads CHANGELOG.md, derived with
grep -rl CHANGELOG test/ --include='*.sh' rather than assumed. The full matrix ran
anyway.

Worth recording: on my last documentation change docs_style caught two em dashes I
had written into a changelog entry, which is a deliberate house rule in that suite. I
checked this one with the checker rather than by eye.

[OffgridwithJD]

Force-pushed: this now carries seven entries rather than six. The seventh is the
vacuum_sorted comment fix that #832's branch used to carry.

Both branches were adding to the same ### Fixed section from different bases, and
each order conflicted on the second merge, while GitHub reported both mergeable because
it compares each against main rather than against the other. The changelog now lives
here alone; #832 keeps only its SQL and source change.

That also changes the count in the summary: four of the seven affect the shipped
v1.0-alpha2, not three. The vacuum_sorted comment is in the shipped full script and
in the upgrade script, so \df+ prints it to a user today.