Sponsorship: entities + Stripe catalog sync (Phase 7.1)

[pablo-clueless]

Scope

New CommunityPro.Sponsorship module (schema sponsorship): tiers, sponsors, invoices, and the Stripe product/price catalog sync.

Tiers: Community Supporter, Member Development Partner, Main Stage Sponsor — recurring subscriptions with monthly + annual prices, plus a one-off "custom contribution" path. (Flagged assumption from the spec: if tiers turn out to be one-off, Checkout mode changes in the follow-up ticket — the model here is unaffected.)

Data model

public sealed class SponsorshipTier
{
    public Guid Id { get; set; }
    public string Name { get; set; }
    public string[] Benefits { get; set; }        // copy lives in DB; prices live in Stripe
    public string StripeProductId { get; set; }
    public string StripeMonthlyPriceId { get; set; }
    public string StripeAnnualPriceId { get; set; }
}

public sealed class Sponsor
{
    public Guid Id { get; set; }
    public string OrgName { get; set; }
    public string ContactEmail { get; set; }
    public string StripeCustomerId { get; set; }
    public string? StripeSubscriptionId { get; set; }
    public Guid TierId { get; set; }
    public SponsorStatus Status { get; set; }     // Active | PastDue | Cancelled
    public string? LogoUrl { get; set; }          // Cloudinary
    public bool ShowInGallery { get; set; }
}

public sealed class SponsorInvoice
{
    public Guid Id { get; set; }
    public Guid SponsorId { get; set; }
    public string StripeInvoiceId { get; set; }
    public long AmountCents { get; set; }
    public string Currency { get; set; }
    public InvoiceStatus Status { get; set; }
    public string HostedInvoiceUrl { get; set; }
    public string PdfUrl { get; set; }
    public DateTimeOffset IssuedAt { get; set; }
}

Catalog sync

dotnet run -- sync-stripe-catalog: idempotently ensures Stripe Products + Prices exist for each tier from config, storing the resulting ids in the DB. Environment-aware — never hardcode price ids (test vs live keys produce different ids). Stripe SDK calls behind a module-owned interface.

Acceptance criteria

• Sync is idempotent (re-run → no duplicate products/prices)
• Tier seed data (names + benefits) migrated
• env.example gains Stripe keys
• xUnit coverage with a fake Stripe client

Conventions (project-wide, non-negotiable)

• .NET 9, records for immutable shapes, file-scoped namespaces, primary constructors where they read well. Minimal-API endpoints grouped per module via IEndpointModule.MapEndpoints.
• Result<T> (SharedKernel) instead of exception-driven control flow. Endpoint results map failures to ProblemDetails with the stable error codes listed above — the frontend keys off them.
• Module owns its EF Core DbContext mapped to its own Postgres schema. Modules never reference each other's internals — cross-module needs go through a public contract interface or an in-process domain event (IEventPublisher).
• All external calls (GitHub, Stripe, Brevo, Cloudinary, Meilisearch) behind interfaces owned by the consuming module.
• Every list endpoint paginated (offset is fine). xUnit tests in tests/CommunityPro.Tests/<Module>/ following the existing harness patterns (see Members/MembersTestHarness.cs).