Populate MaxConcurrentRebuildsPerDatabase + per-cell rebuild cancellation parity in TryCreateUsage

[jeremydmiller]

Goal

Polecat parity for JasperFx/marten#4710:

1. Populate MaxConcurrentRebuildsPerDatabase on the descriptor. Once jasperfx#434 adds the field, Polecat's IEventStore.TryCreateUsage should populate it from the equivalent Polecat projection-graph setting. Pattern mirrors PS#3's polecat#179 (ProjectionErrorHandlingDescriptor).

2. Per-cell rebuild cancellation semantics. Confirm IProjectionDaemon.RebuildProjectionAsync(name, tenantId, ct) leaves pc_event_progression in a consistent state when the cancellation token fires.

Why

CritterWatch#309 — the long-running projection rebuild orchestration feature — needs identical behaviour from Polecat-backed monitored services to land Polecat parity tests in PR 6 of the implementation plan.

Companions

• jasperfx/jasperfx#434 — descriptor field definition.
• jasperfx/marten#4710 — Marten-side companion (same two items).

Out of scope

Per-database cap overrides — matches the Marten-side scope.

[jeremydmiller]

De-prioritized: CritterWatch is pausing #309 (the orchestration consumer this issue services) until after the CritterWatch 1.0 release. Leaving this open with a clear status — not abandoned, just downstream-paused. We'll re-engage with this surface once CritterWatch 1.0 ships and the design pass (https://github.com/JasperFx/CritterWatch/pull/338, now in draft) resumes. Feel free to scope / land if it's convenient on your side independently; we'll consume when we're ready.

[jeremydmiller]

Item 2 (per-cell rebuild cancellation consistency) is done — PR #184 (merged).

Verifying the behavior surfaced a real gap: the per-tenant rebuild teardown (DeleteProjectionProgressAsync(name, tenantId, ct)) wasn't atomic and leaked a raw SqlException on cancellation. It now runs in a single transaction (so a cancel leaves pc_event_progression fully applied or fully rolled back — never half-reset) and surfaces a clean OperationCanceledException. Covered by cancelling_a_per_tenant_rebuild_keeps_progression_consistent.

Item 1 (populate MaxConcurrentRebuildsPerDatabase) remains blocked — that EventStoreUsage field is not in JasperFx.Events 2.9.8 (jasperfx#434 not yet released). Once it ships, IEventStore.TryCreateUsage should populate it, mirroring the ProjectionErrorHandlingDescriptor work in #179. Leaving this issue open to track item 1.

[jeremydmiller]

Closing — both items are already implemented and covered by tests.

Item 1 — populate MaxConcurrentRebuildsPerDatabase on the descriptor.
Done in commit 3321c64 (jasperfx#420/#434/#463). IEventStore.MaxConcurrentRebuildsPerDatabase resolves the cap (explicit StoreOptions.DaemonSettings.MaxConcurrentRebuildsPerDatabase wins; otherwise max(1, MaxPoolSize / 8) from the SqlClient pool), and TryCreateUsage populates it onto the descriptor (DocumentStore.EventStore.cs). Covered by rebuild_concurrency_cap_resolution.cs.

Item 2 — per-cell rebuild cancellation consistency.
Covered by cancelling_a_per_tenant_rebuild_keeps_progression_consistent in src/Polecat.Tests/Daemon/per_tenant_rebuild_tests.cs, which is explicitly tagged polecat#180 (item 2). It asserts that cancelling RebuildProjectionAsync(name, tenantId, ct) leaves pc_event_progression consistent — other tenants untouched, and the cancelled tenant never advances past the events that exist (progress + projected data commit atomically per batch).

Nothing left to do here; reopen if the CritterWatch#309 parity tests surface a gap.