RAII things - #759

SQLite pools now build through CountingSqliteManager, and the build sites
in get_or_create_shared_pool report creation and cache reuse.

census_workload, ten surfnets built and dropped per phase:

    on-disk:   pools 10 (+180 reuses), conns opened 100, closed 0,
               100 still live after the last drop
    in-memory: pools 190, conns opened 1,900, closed 1,900,
               peak 190 live during one surfnet

Connections owned by the process-global SHARED_POOLS survive every
surfnet drop. The in-memory line prices the 19 isolated pools each
surfnet builds.

Co-authored-by: Claude <noreply@anthropic.com>

…ions

Each surfnet now opens one StorageBackend from its database URL and mints
all of its kv stores from it. The SQLite pool moves off the process-global
SHARED_POOLS map onto the backend, so connections live exactly as long as
the surfnet that opened them; the checkpoint-dedup set and the per-store
shutdown fan-out fall away with it. PostgreSQL keeps its process-level
pool cache behind the backend, where pooling actually amortizes a network
connection. In-memory SQLite now shares one database per surfnet instead
of building 19 isolated pools, matching the on-disk layout of distinct
tables in one database.

The counting manager remains the pool's connection type, so connection
opens and closes stay counted; the census build-site hook is reconnected
in the next commit.

Co-authored-by: Claude <noreply@anthropic.com>

SqliteBackend::open reports pool creation, and a new assertion test,
dropping_backend_closes_connections, fails if any connection opened by a
backend survives its drop.

census_workload, same workload as the baseline measurement two commits
back:

    on-disk:   pools 10, conns opened 100, closed 100, live 0
    in-memory: pools 10, conns opened 100, closed 100, live 0

Ten dropped surfnets leave 100 connections live on the baseline and none
here; in-memory construction opens 190 connections per surfnet there and
10 here.

Co-authored-by: Claude <noreply@anthropic.com>

Counting stays always on: the counters are a handful of relaxed atomics
bumped at pool and connection lifecycle events, which are rare next to
queries, so there is nothing worth stripping from a release build. What
was missing was a way to see the movement outside a test harness.

Each counter now emits a debug line under this module's log target, so
RUST_LOG=surfpool_core::storage::census=debug turns on reporting in any
build, including shipped binaries. That matters for field diagnosis:
when someone hits descriptor exhaustion, the ask is an env var and a
re-run, not a from-source build. It also keeps a single pool type in
every configuration, so tests exercise exactly what ships.

The census tests initialize env_logger (is_test, same pattern as the
integration suite) so harness runs show the per-event narrative next to
the snapshot deltas.

Note the event ordering in the logs: "pool created" appears after its
connections open because r2d2 fills the pool eagerly inside build(),
and we count the pool only once the build succeeds.

The census did its job: the baseline and fix measurement commits carry
its numbers, and an external fd sampler reproduces the on-disk result
from outside the process (peak 434 SQLite descriptors on the shared-pool
baseline against 23 with backend-owned pools, over the same workload of
31 on-disk tests). The evidence for the refactor no longer needs
counters in the tree, and keeping them would mean a counting wrapper
inside the shipped pool type forever, a larger maintenance surface than
a merged fix should carry.

SqliteBackend builds on a plain ConnectionManager again, so the pooled
connection loses one deref hop and the pool type is identical in every
configuration. The pre-removal tip is tagged census-archive; the
counters, the Drop-based close accounting with its r2d2 on_release
subtlety, and the workload harness live there if this leak class ever
needs exact instrumentation again.