Alpha gate: assert and document the blast radius of a single backend crash

[jdatcmd]

Alpha gate 4 of 4, from the pre-alpha review note. @ChronicallyJD for review.

What is true today

The note asks that a backend crash be confirmed and documented to drop
connections and reinitialize without corrupting committed columnar data, and
says explicitly that this should be an asserted guarantee rather than an
inference from repros. It is currently an inference.

test/recovery.sh covers a neighbouring scenario, not this one. It SIGKILLs the
entire postmaster process group, using a negative-PID kill so the backends die
with it, then restarts into crash recovery and asserts two things against a heap
mirror: committed writes replay, and an in-flight uncommitted write leaves
nothing visible. It also confirms recovery actually ran by finding a redo entry
in the log.

That is whole-cluster crash and restart. The scenario the note is about is one
backend dying while the postmaster lives, which is the #210 shape: a SIGSEGV in
a parser takes down a single backend, the postmaster reinitializes shared
memory, and every other session is dropped. Whether committed columnar data is
intact on the other side of that is not asserted anywhere.

Nothing in the documentation states the guarantee either. grep -niE 'crash|blast radius|never corrupt|committed data' over docs/limitations.md
and docs/ARCHITECTURE.md returns nothing.

Why the guarantee is arguable rather than hopeful

The header of test/recovery.sh states the mechanism: columnar data lives in
the relation main fork through the buffer manager and WAL, and metadata lives in
WAL-logged heap catalogs. If that holds with no exception, a single backend
death is no different from any other backend death in PostgreSQL, and the
guarantee follows from core rather than from this extension. The work is to
confirm there is no exception, not to build a new mechanism.

The thing to look for is any write path that bypasses the buffer manager or
leaves shared state that a dead backend does not clean up. Two candidates worth
checking specifically rather than assuming: an in-progress write state flushed
partially at the point of death, and any cache or shared allocation whose
invariant a dead backend leaves broken for the next one.

Plan

Add the single-backend-death scenario to the crash suite, then write the
guarantee down with the conditions under which it holds.

Todo

• Add a scenario to test/recovery.sh, or a new suite if it does not fit,
  that kills one backend mid-write with SIGSEGV or SIGKILL while the
  postmaster lives.
• Assert in that scenario: the postmaster survives and reinitializes; other
  sessions are dropped and the cluster accepts new connections; data
  committed before the kill matches the heap mirror exactly; the partial
  write leaves no visible rows and no partial row group.
• Repeat the kill at several points in the write path, including mid-stripe
  and between a group flush and the commit, rather than at one point.
• Audit for exceptions to the buffer manager and WAL statement above, and
  name any found in the issue. An exception is a defect, not a caveat to the
  guarantee.
• Run the same scenario against a table under concurrent readers, since the
  dropped-connection half of the claim is about other sessions.
• Write the guarantee into docs/limitations.md or docs/ARCHITECTURE.md,
  stating what survives a backend crash, what does not, and that it rests on
  columnar data going through the buffer manager and WAL.
• Add the suite to the SUITES array in test/run_all_versions.sh, or it
  is never gated.

What closes this

A suite that fails if the guarantee is broken, and a documented statement of the
guarantee that cites the mechanism it rests on. The inference from #210 repros
is not enough on its own.

The set

Alpha gates from the pre-alpha review note, ranked cheapest-highest-value first:
#214 fuzz the parsers, #215 limitations and release status, #216 untrusted-input
boundary, #217 backend-crash blast radius.

[jdatcmd]

Closed by #223 (5cf5c09).

Every item on this issue's todo is done and verified:

• test/native_backend_crash.sh SIGSEGVs one backend while the postmaster
  lives, at three points: mid-write, after the stripes flush but before a commit
  that never comes, and with a concurrent reader attached.
• Asserts the postmaster survived with the same pid, the cluster accepts new
  connections, committed content matches a heap mirror exactly, the mirror is
  unchanged, the killed insert left no visible rows and no partial row group, and
  other sessions were dropped.
• The audit for exceptions came back clean, which is the strongest form this
  guarantee could take: grep -nE 'smgrwrite|FileWrite|pg_pwrite|\bwrite\(' over
  columnar_storage.c, columnar_write_state.c and columnar_metadata.c
  returns nothing, and columnar_storage.c has 10 log_newpage* /
  XLOG_SMGR_TRUNCATE sites. Nothing bypasses the buffer manager, so a single
  backend death reduces to core's behaviour rather than to anything this
  extension does.
• The guarantee is written down in docs/ARCHITECTURE.md under "Crash safety",
  citing both suites and the mechanism it rests on.
• Registered in run_all_versions.sh, so it is gated.

The reason it took two rounds is worth keeping: the first version passed 19/19
with the kill -SEGV removed, on all but one check. The insert is uncommitted by
design, so "no visible rows" and "matches the mirror" are the outcome whether the
signal lands or the backend merely aborts. Every scenario now opens a sentinel
session before the kill and asserts the reinit dropped it, because a plain
backend exit drops only itself while a crash-triggered reinit drops everything.
Re-running the same experiment now turns four checks red across all three
scenarios instead of one.

25 checks, about 8 seconds.

Two of the four alpha gates are now closed: this and #215. #214 stays open for the
Arrow half and a real soak; #216 is untouched.