Test conjoined EF Core tenant partitioning alongside a mix of Marten/Polecat conjoined tenancy in one database

[jeremydmiller]

Follow-up from the conjoined EF Core multi-tenancy epic (#3465).

The conjoined EF Core tenancy work (Phases 1–3, shipped for 6.21 via #3498) and its Weasel-managed partition-per-tenant support are currently exercised against an EF-Core-only database. We should add coverage for the mixed-persistence scenarios that a real Critter Stack app will actually hit, where more than one tenancy system manages partitions/tenants in the same physical database:

Scenarios to cover

1. EF Core (Wolverine-managed conjoined partitioning) + Marten conjoined tenancy in one database

   • Verify the two partition-control worlds coexist: Weasel's wolverine_tenant_partitions vs Marten's mt_tenant_partitions, and the wolverine_tenants registry alongside Marten's own tenancy metadata.
   • Confirm tenant add/disable/remove through Wolverine's IDynamicTenantSource<string> and through Marten don't step on each other, and that partitions are created/dropped for each engine's own tables only.
   • Cross-tenant read/write isolation holds for both EF entities and Marten documents in the same DB.

2. EF Core (Wolverine-managed conjoined partitioning) + Polecat conjoined tenancy in one database

   • Same coexistence checks against Polecat's tenancy/partitioning (note Polecat per-tenant partitioning parity is still tracked in Per-tenant managed partitioning parity with Marten (documents + streams) polecat#335 — this scenario may be gated on that landing).

Why not now

Out of scope for the 6.21 docs/sample PR; noted as a deliberate follow-up. These need a multi-store test rig (EF + Marten and EF + Polecat sharing a Postgres database) and should assert both partition DDL ownership and tenant-lifecycle isolation across the engines.

Related: #3465, #3463 (Phase 2 partitioning), #3464 (Phase 3 registry), JasperFx/polecat#335.