Fix #4683 (fixes 1+2) — drop per-tenant sequence + progression rows on tenant removal

[jeremydmiller]

Closes the first two fixes from #4683 (fix 3 — drop → re-add scale test in Marten.ScaleTesting — split as a follow-up per the "one focused PR at a time" preference).

Under UseTenantPartitionedEvents, dropping a tenant via either DeleteAllTenantDataAsync or RemoveMartenManagedTenantsAsync removed the partition tables but left two side-tables orphaned:

Leak	Where
Freestanding mt_events_sequence_{suffix} sequence	Created without OWNED BY, so the partition drop skips it. Every drop-add cycle accumulated another sequence.
Per-tenant mt_event_progression rows	One per projection's {Projection}:All:{tenantId} catch-up plus the HighWaterMark:{tenantId} row. Silent leak.

Both were originally pinned in delete_all_tenant_data_orphan_sequence_pin.cs (#4617 section 3e deferred items) as documented bugs awaiting a fix.

What ships

File	Role
Marten.Internal.PerTenantPartitionedCleanup	New helper. CaptureSequenceSuffixes(...) runs BEFORE the partition drop (Weasel may clear the tenant entry); RunAsync(...) runs the batched DROP SEQUENCE + DELETE FROM mt_event_progression afterwards.
TenantDataCleaner.ExecuteAsync	Routes through the helper after the partition drop + table DELETEs.
AdvancedOperations.RemoveMartenManagedTenantsAsync	Now also routes through the helper (this path skipped TenantDataCleaner entirely before, so it had to be wired separately).

Per-tenant mt_event_progression rows are identified by parsing the ShardName grammar rather than LIKE-matching the row name -- so a projection whose name happens to end with a tenant id is never mistakenly deleted. Two grammars handled:

• HighWaterShardIdentity.PerTenantPrefix exact match (Marten's per-tenant HighWater grammar -- ShardName collapses HighWaterMark identities to the constant, so they don't round-trip through ShardName.TryParse).
• ShardName.TryParse for everything else, across Name:ShardKey:Tenant and the versioned Name:V{n}:ShardKey:Tenant form.

Store-global rows (HighWaterMark, MyProjection:All, etc) never match -- no tenant slot. Verified explicitly via direct progression-row seeding in the test.

Tests

The pre-existing pin in delete_all_tenant_data_orphan_sequence_pin.cs is flipped from ShouldBeTrue(\"...the orphan leak\") to ShouldBeFalse(\"...now drops...\"). The two original cases (DeleteAll path + RemoveMartenManagedTenants path) now verify the fix instead of pinning the bug.

A third case, DeleteAllTenantDataAsync_removes_per_tenant_progression_rows_and_preserves_store_global, seeds 8 progression rows directly via SQL spanning all three grammars + store-global + versioned variants and asserts:

• Dropped tenant's rows removed across all three grammars (HighWaterMark + :All: + versioned :V2:All:).
• Keep tenant's rows untouched.
• Store-global HighWaterMark and SomeProjection:All rows preserved.

Suite	Result
TenantPartitionedEventsTests	178/178 on net9.0
MultiTenancyTests (touches RemoveMartenManagedTenantsAsync)	146/146 on net9.0
CoreTests	432/435 — 2 of those failures are a pre-existing flake confirmed on master (partitioning_and_foreign_keys.* shared-schema state); the test passes alone on both branches

Docs

docs/events/multitenancy.md gets a new "Dropping Tenants" subsection under "Per-Tenant Event Partitioning" that documents both routes, preservation of store-global rows, and the ShardName-grammar-based row identification.

Followups

• Drop-tenant cleanup gaps under UseTenantPartitionedEvents (orphaned sequences + progression rows) #4683 fix 3 — drop → re-add scale test in Marten.ScaleTesting (20M events, full cycle). Separate PR.
• Structural cleanup — declare each mt_events_sequence_{suffix} as OWNED BY its partition table at creation time so the partition drop drops the sequence automatically. Needs a schema migration for existing deployments; deferred as a structural follow-up. This PR handles both new and existing deployments today.

🤖 Generated with Claude Code