Isolate notification maintenance workers from request scope

[SadPossum]

Summary

• add a private notification-maintenance DbContext factory for cross-scope worker writes
• route durable delivery claim/completion and retention cleanup through that isolated context
• preserve ordinary request-scope filtering and admission, closed-scope fencing, scope revisioning, provider locks, transactions, and cancellation semantics
• reuse the exact configured EF options, including the existing custom-DbContext replacement seam

Why

In a scope-enabled host, background DI scopes do not have an active request scope. The delivery and retention workers queried across scopes but saved through the ordinary request-scoped context, so valid maintenance writes were rejected. Completion failures after a provider send could also leave a delivery leased for later at-least-once redelivery.

Verification

• ./eng/verify.ps1 passed on the exact commit
  • solution sync and module-boundary checks
  • restore and build with 0 warnings / 0 errors
  • PostgreSQL and SQL Server migration-drift checks
  • 136/136 non-Docker tests
  • 11/11 Docker-backed relational tests
  • transitive vulnerable-package audit: none reported
• repository security and release-policy checks passed
• touched production files passed dotnet format --verify-no-changes
• independent exact-diff reviews found no P0/P1 blocker

The relational coverage runs workers with tenancy enabled and no active request scope, spans multiple open scopes, proves closed-scope claim/completion/retention exclusion, and retains PostgreSQL/SQL Server locking and lease-recovery assertions.

Scope boundaries

• no public API or contract change
• no schema, model, snapshot, or migration change
• no delivery-provider behavior change; delivery remains intentionally at-least-once
• no StayQuest consumer-pointer change in this repository
• no deployment or live-provider evidence claimed

Separate pre-existing hardening work remains for set-based write/revision atomicity, database-enforced monotonic scope-state revisions, and SQL Server ordinal collation of broadcast recipient scopes.

[ArtemQuestful]

Verification refresh — 2026-09-05

Resumed the existing clean worktree and exact head a9fe933f7d1e771184f7835b73e2a379fb16a53a; no new branch, commit or implementation was created. Current dev is still 5cbb3d32329598555f6dc9da363753b4be4b148c.

Against the unchanged StayQuest-pinned GMA Framework bdc508208f84a4b85bb7ab39850c6065086c56c4, serialized Release verification passed:

• Notifications unit suite: 136 passed, 0 failed, 0 skipped.
• Required real PostgreSQL tests: 2 passed, 0 failed, 0 skipped: Delivery_claims_are_disjoint_and_batch_processing_honors_concurrency (including lease/worker recovery) and Retention_deletes_only_completed_history_and_advances_reference_versions_on_postgresql (including maintenance retention).
• Independent source review of this eight-file diff: no actionable P0–P2 findings; request-scoped contexts remain separate from internal maintenance contexts and existing scope-closure/mutation guards remain intact.
• Clean worktree and whitespace check confirmed after execution.

This is fresh local PostgreSQL/unit proof, not a new hosted run or fresh SQL Server execution. Existing hosted checks from August 22 remain historical evidence. PRs #19/#20 and the superseded Auth bridge are excluded. Source advance and consumer pin coordination remain separate; no shared dev branch or consumer pin has been changed by this refresh, and no real email-delivery/production admission is claimed.

[ArtemQuestful]

Consumer-train coordination hold — 2026-09-05

The exact head remains a9fe933f7d1e771184f7835b73e2a379fb16a53a, independently reviewed with fresh 136 unit + 2 required PostgreSQL tests passing (see prior refresh). No source edits or replacement branch are needed.

A live consumer audit confirmed that active consumer CI compares committed source pins against upstream dev. Advancing this PR alone would invalidate those freshness gates until their coordinated pin updates land. Keep this PR unmerged/draft until the responsible consumer owners acknowledge a source/pin update sequence; no consumer worktree or pin has been changed.

Attempts to refresh the two existing hosted runs were denied by the repository's Actions permission check. Therefore the August 22 hosted evidence is still historical, not a rerun today. No Actions policy or check was bypassed. The fresh local verification and this coordination hold do not claim deployed delivery, transport availability, or production admission.