Partition manager cannot reclaim a pre-existing catch-all partition — monthly partitioning silently stops

**Summary**

Once a fresh deployment's initial migration boundary is crossed, `ensure_future_partitions` can never create the "current month" partition again, because the migration's own `*_p_future` catch-all already covers that range. The collision is caught and swallowed as a benign, expected case — so partitioning for that range silently and permanently stops, with no error, no metric, and no operator-visible signal beyond a Postgres server-log line most people don't watch.

**Where**

- `migrations/0001_initial_schema.sql` (events: lines ~237-252, `delivery_log`: lines ~343-354) hardcodes monthly partitions with literal dates authored mid-2026, ending with a catch-all:
```sql
CREATE TABLE events_p_future PARTITION OF events
FOR VALUES FROM ('2026-07-01') TO (MAXVALUE);
```
Any fresh install that runs this migration in July 2026 or later will have every monthly partition `ensure_future_partitions` tries to create fall inside `_p_future`'s range and collide. This isn't an edge case — it will recur for every fresh install going forward, and again at the *next* catch-all boundary for any host that hand-repairs it (e.g. re-basing to `2027-01-01` just moves the wall to 2027-01).

- `crates/buzz-db/src/partition.rs` (~lines 130-149) explicitly anticipates this:
```rust
match sqlx::query(sqlx::AssertSqlSafe(sql)).execute(pool).await {
Ok(_) => { info!("added partition {partition_name}"); Ok(()) }
Err(sqlx::Error::Database(db_err))
if db_err.code().as_deref() == Some("42P17")
&& db_err.message().contains("would overlap partition") =>
{
// Fresh schemas include a right-edge catch-all partition (`*_p_future`).
// If it already covers this month, the table is still safe for writes;
// treat the overlap as "ensured" rather than failing startup.
info!(partition_name, "partition range already covered by an existing partition");
Ok(())
}
Err(e) => Err(e.into()),
}
```
Postgres error `42P17` ("would overlap partition") is caught and logged at `info`, then treated as success. Postgres itself still logs a server-side `ERROR` for the rejected DDL (independent, unsuppressable), but the application never surfaces it, never fails startup, and gives no indication that the monthly partition was never actually created.

**Impact**

The monthly partition never gets created; nothing ever shrinks or re-splits the existing catch-all. Every row for the colliding range keeps landing in `_p_future` indefinitely, defeating the purpose of monthly partitioning (pruning/archival/maintenance by partition boundary). There's no code anywhere in `partition.rs` or in migrations `0002`-`0026` that ever reclaims or splits an existing catch-all partition once one exists.

**Reproduction**

A regression test reproducing this against real Postgres (`current_month_partition_is_never_created_once_a_future_catchall_exists`, `crates/buzz-db`) is here, passing in CI: https://github.com/frodoHost/buzz/pull/1

**Suggested fix direction** (not implemented)

Either detach-and-recreate the overlapping range of `_p_future` when a monthly-partition collision is detected, or raise the `info!` to a `warn!`/metric so this isn't purely a Postgres-log-only symptom.

Start in crates/buzz-db/src/partition.rs around the 42P17 overlap handling, then inspect the events and delivery_log definitions in migrations/0001_initial_schema.sql. Run current_month_partition_is_never_created_once_a_future_catchall_exists against real Postgres and use it to verify that the chosen behavior no longer leaves a colliding monthly range silently unpartitioned.

Written by the indexing model from the issue text.