Add test_bufmgr: algorithm-agnostic tests for the buffer manager

[cooltodinesh]

Summary

The buffer manager (src/backend/storage/buffer/) has no test module of its
own. It is covered only incidentally, as a side effect of the rest of the
regression suite, so a change to the replacement policy or to the residency
bookkeeping can regress without any test asserting the affected property
directly.

This adds src/test/modules/test_bufmgr: tests for the buffer manager as a
subsystem, not for any one replacement algorithm. The module is named for the
subsystem under test, which is stable, rather than for the current eviction
policy, which is not.

Everything asserted is a property any correct buffer manager must have,
expressed only through observable behavior — page residency, page contents,
buffer pins. Residency is read as "does pg_buffercache have a row for this
relation block", contents as the page data itself, pins as
pg_buffercache.pinning_backends. No test reads usagecount or any other
replacement-policy internal, and no test predicts which buffer is chosen as a
victim, so the suite should keep passing across an algorithm swap — including
to a pool that has no usagecount field at all.

What's here

Seven regress tests and one isolation spec:

• eviction_reload — an evicted page reloads with correct contents, and the
  manager makes progress under pressure (no "no unpinned buffers available"
  error).
• dirty_persistence — an evicted dirty page reloads with its modified
  contents. No checkpoint or restart needed: eviction itself forces the
  write-out. (Verified directly that CHECKPOINT clears the dirty bit without
  evicting, so a background checkpoint stealing the write would make the
  assertion pass for the wrong reason rather than fail — hence
  checkpoint_timeout = 1h in the test config; see README for the mechanism.)
• scan_no_retain — a one-touch page does not indefinitely retain its buffer
  under pressure.
• truncate_stale / drop_recreate_stale — TRUNCATE and DROP+recreate
  never let stale cached pages resurface.
• local_eviction — the local (temp-table) buffer pool reuses correctly,
  sized from temp_buffers in bytes so it holds at any BLCKSZ.
• churn — contents stay correct after many replacement cycles over a working
  set several times the pool.
• pinned_safety (isolation) — a buffer pinned via a suspended cursor in one
  session survives a concurrent flood in another session, with an unpinned
  control probe confirming the flood actually exceeded the pool (guards against
  a vacuous pass).

What keeps it from being tied to one configuration

• Pressure via pg_prewarm('rel', 'buffer'), not plain scans. Prewarm's
  buffer mode pulls blocks in through the normal replacement path with no
  BufferAccessStrategy ring, unlike a sequential scan or COPY, which take a
  ring and so never cycle the whole pool.
• Sizes derived from GUCs in bytes (shared_buffers / temp_buffers ×
  block_size), not a hand-tuned row count, so working sets exceed the pool at
  any BLCKSZ rather than at one config.
• Self-calibrating floods: where a fixed size will not do, the test loops,
  adding pressure until the observed end state occurs (a tracked block goes
  non-resident), bounded by a generous round cap, instead of asserting that a
  fixed size happened to be right on this machine.

Scan resistance: attempted and dropped

I tried a "hot page survives a one-touch flood" test and pulled it after
validating it across configurations:

• It is not universal — a hot page is not necessarily kept resident against a
  greater-than-pool flood at the test pool size, because the flood's own bulk
  read/write pressure churns the pool. It is a property of a scan-resistant
  replacement policy, not of every correct buffer manager.
• Even where it holds, it is geometry-dependent and non-monotonic: over the same
  8MB pool the outcome flipped between 1024 buffers (8kB BLCKSZ), 256 (32kB) and
  2048 (4kB), because whether a page survives depends on how many times a
  greater-than-pool sweep revisits its slot, regardless of how hot it is.

It is recorded as a TODO in the README — a real version needs injection-point
control over buffer placement (or a comparative hit-ratio measure), not a single
post-flood residency check. The README lists the other deferred cases too
(crash durability across restart, bgwriter as a first-class subject, concurrent
reads of the same block, cleanup-lock acquisition, async/streaming reads, I/O
failure handling, checkpoint/writeback interactions).

Verified

• Green and deterministic (repeated runs, no flakiness) on current master and
  on REL_17_STABLE.
• Green at BLCKSZ 4/8/16/32 kB.
• NOTICE output from CREATE EXTENSION IF NOT EXISTS / DROP ... IF EXISTS
  is suppressed via client_min_messages = warning in the test config
  (server-level, not per-statement SET), so expected output isn't coupled to
  schedule order.

Happy to iterate on the scan-resistance tradeoff, on which properties are worth
asserting first, or on anything else.