Fix managed LIST partitions destructively rebuilt under multi-database apply (marten#4706)

[jeremydmiller]

Fixes the Weasel side of JasperFx/marten#4706. Bumps to 9.1.1.

Problem

A single ManagedListPartitions instance is shared across every database in a store. Under sharded multi-tenancy each database has its own mt_tenant_partitions contents, and Marten's ApplyAllConfiguredChangesToDatabaseAsync runs the databases in parallel. The manager's one-shot _hasInitialized cache therefore held the first database's partition set, so every other database's table diff saw the existing per-tenant partitions as "unexpected" and destructively rebuilt the table (create <t>_temp as select * → drop → recreate → copy), failing with 23514: no partition of relation found for row.

Fix

• Per-database load cache. Replace the one-shot _hasInitialized bool with _initializedFor, keyed on the connection's DataSource/Database, so InitializeAsync reloads when pointed at a different database. Single-database stores still load exactly once. ForceReload() now clears the key.
• Additive bypass. additivelyMigrateTablesForNewPartitions clears IgnorePartitionsInMigration locally so the explicit AddPartitionToAllTables path still creates partitions even when a consumer (Marten) sets that flag on managed-partition tables to exempt them from the generic schema diff.

This is the Weasel half; the Marten side (marten#4706) sets IgnorePartitionsInMigration on its Marten-managed partitioned tables so the generic diff returns None for them (no rebuild), while partition creation continues through the additive path enabled here.

Tests

managed_list_partitions gains:

• a rebuild guard — a managed table with IgnorePartitionsInMigration set is not destructively rebuilt by the generic diff over its existing partitions (CreateMigrationAsync → None);
• an additive-bypass guard — AddPartitionToAllTables still physically creates the child partition with the flag set.

Full partition + migration suite green (111).

🤖 Generated with Claude Code

[jeremydmiller]

Correction (9.1.1 → 9.1.2). The per-database reload that shipped in 9.1.1 (_initializedFor key + _partitions.Clear()) is regressive under sharded multi-tenancy: the prior one-shot loader accumulated the union of all tenants, and sharded lazy event-partition creation relies on that union (the manager isn't a per-shard initializer), so clearing it built shard tables with the wrong tenant set → 23514 on mt_streams. It was also unnecessary — the destructive rebuild on redeploy is prevented by the consumer setting IgnorePartitionsInMigration on managed-partition tables (CreateDelta → None).

This branch now restores the one-shot loader and keeps only the additive bypass. Verified against Marten: sharded redeploy repro RED→GREEN, TenantPartitionedEventsTests 182/182, CoreTests partitioning 33/33, Weasel managed_list_partitions 11/11 per TFM. Bumped to 9.1.2.