Make managed tenant partition bucketing actually share a partition (#391)

[jeremydmiller]

Closes #391.

Both managed-partition strategies advertise multi-tenant bucketing — several small tenants sharing one
physical partition to stay clear of per-table partition ceilings — but neither could express it end to end.
Both halves reproduced against real PostgreSQL and SQL Server before fixing.

PostgreSQL — ManagedListPartitions

AddPartitionToAllTables emitted one single-value ListPartition per value, so two values sharing a suffix
produced two CREATE TABLE IF NOT EXISTS statements against the same partition table name. The first created
it with only its own value; the second was silently swallowed. The partition never accepted the second value,
and that tenant's first write died with 23514 no partition of relation found for row.

The additive path now groups by sanitized suffix — that is what names the physical table — and carries the
bucket's full membership, not just the values supplied in the current call. Since CREATE TABLE IF NOT EXISTS
cannot alter an existing bound, widening a partition that is already there is DETACH + re-ATTACH inside
one transaction; a failure between the two would orphan the partition and leave every tenant in the bucket
unroutable.

Also fixed here: co-tenant data loss on drop

DropPartitionFromAllTablesForValue resolved a value to its suffix and then dropped by suffix — deleting
every registry row in the bucket and DROPping the shared partition table. Removing one small tenant therefore
silently destroyed its co-tenants' rows. It now narrows the bucket instead: only the departing value's rows are
deleted, the partition is re-bound to the remaining members, and the partition is released only with the last
member. Filed as JasperFx/wolverine#3686.

SQL Server — ManagedTenantPartitions

Bucketing worked inside a single batch, because the caller supplied the shared ordinal itself. Across calls —
the natural tenant-onboarding shape, and the one the Wolverine docs showed — it silently did not. The registry
persisted only tenant_id -> ordinal, so a brand-new tenant had no way to discover which ordinal its bucket
already owned; each call allocated a fresh one and the tenants never actually shared. The 15,000-partition
ceiling bucketing exists to dodge was not mitigated at all.

The registry gains a nullable bucket column, plus a bucket-aware AddPartitionsToAllTables overload taking
tenant -> bucket. Deliberately a column rather than the pseudo-tenant row considered in #391: a row
would keep the ordinal referenced forever, defeating release-on-last-member and therefore
TenantDropBehavior.DeleteData. A bucket is forgotten once its last member is dropped.

New public surface: the IReadOnlyDictionary<string, string?> overload of AddPartitionsToAllTables, and a
Buckets map. Nothing existing changed shape, and the new column is nullable and additive, so it migrates onto
an existing registry.

Verification

Real PostgreSQL and real SQL Server, not mocks.

• 5 new PostgreSQL tests, all 5 red on 9.19.1 and green here — covering in-batch bucketing, sequential
  bucketing, non-destructive widening, co-tenant survival on drop, and release-on-last-member.
• 5 new SQL Server tests. These exercise new API so they cannot compile against 9.19.1; the underlying defect
  was instead reproduced on 9.19.1 through the old API in the documented sequential shape, which allocated two
  distinct ordinals where one was expected.
• Full suites green: Weasel.Postgresql 780/783 and Weasel.SqlServer 323/331 (skips pre-existing).

Downstream: JasperFx/wolverine#3683 adopts this and adds bucketing compliance coverage on both engines.