Implement the Transactional Outbox Pattern for our .NET 8 API and Azure Service Bus

We have a .NET 8 Web API running on Azure App Service with Azure SQL and Azure Service Bus. Right now, our order flow performs a dual write: it saves the order to SQL and then publishes an `OrderCreated` event to Service Bus. The issue is that a couple of times each week, the SQL transaction succeeds but the Service Bus publish times out. The order is stored successfully, but downstream systems never receive the event. We usually catch it later through a reconciliation report and replay it manually, which isn't a long-term solution. We know the right fix is the Transactional Outbox pattern, but we haven't had the bandwidth to implement it properly. We're looking for someone who can build it for this one workflow so we can use it as the reference implementation for the rest of our events. We're looking for: - An Outbox table that's written in the same EF Core transaction as the Order - A `BackgroundService` dispatcher that polls the outbox and publishes messages with at-least-once delivery semantics - Exponential backoff for retries - Service Bus `MessageId` mapped to the outbox row's primary key so we can take advantage of duplicate detection - Poison message handling that parks a row after a configurable number of failed attempts and emits a metric so we can alert on it - A short write-up explaining the delivery and ordering guarantees of the implementation, along with the guarantees it does not provide, so downstream teams understand the tradeoffs We're intentionally not looking for Hangfire. We'd like this implemented as a plain hosted `BackgroundService` so we can understand the underlying pattern and extend it ourselves over time. To make sure you've read the project description, please answer this in the first two sentences of your proposal: Would you implement the dispatcher as a polling worker or using SQL CDC + Debezium, and why? We skip generic, copy-and-paste proposals.