perf(wintermute): create bulk staging tables once per connection

[afbase]

Stacked on the client_min_messages change; review that one first.

Each bulk path issued CREATE TEMP TABLE IF NOT EXISTS for its staging table on every
batch. Pools recycle with RecyclingMethod::Fast, which never discards temp tables, so
after the first batch on a connection that DDL did nothing but raise a duplicate_table
NOTICE and pay for a catalog lookup.

This hoists the eleven declarations into BULK_STAGING_DDL and runs them once per
connection from a post_create hook in a new config::create_pg_pool. The batch paths
now only TRUNCATE.

The invariant that introduces is that a pool whose connections reach indexer::bulk must
be built by create_pg_pool, or those paths fail with undefined_table. The indexer
pools, the indexer test pool, and the car_loader, direct_index and firehose_catchup
binaries are the pools that reach it, and all now route through it. The ingester pools do
not reach the bulk paths and are unchanged. A test asserts every truncated table is
declared, because drift there surfaces at runtime rather than in review.

Test plan

• cargo clippy -p rsky-wintermute --all-targets --no-deps -- -D warnings
• cargo test -p rsky-wintermute against a database with the appview schema — the
  indexer::tests suite is what actually exercises the staging tables
• cargo build --release -p rsky-wintermute
• direct_index indexes a repo end to end on a fresh connection
• car_loader loads a CAR end to end
• firehose_catchup drains a backlog
• Indexer throughput unchanged, and no undefined_table errors in the logs