fix(outbox): provider-aware PerKey guard + OrderedConsumers sample 2PC fix

[asawicki]

Summary

Two related changes in the outbox area, hardening the transactional outbox and fixing the
OrderedConsumers sample so it actually delivers end to end.

1. Outbox hardening (fix(outbox): …)

• Provider-aware PerKey ordering guard. The startup guard now enforces a dialect's
  head-of-line capability only when that dialect is the active claim path (the active EF Core
  provider matches the dialect ProviderName). When another provider is active, the store uses the
  client-side fallback claim, which enforces per-key head-of-line ordering itself — so a valid
  single-instance deployment is no longer falsely rejected at startup or forced to set
  AllowDegradedOrdering.
• Cleanup startup gating. OutboxCleanupService's destructive DELETEs are gated on
  IHostApplicationLifetime.ApplicationStarted, mirroring the dispatcher, so cleanup never runs from
  a process that never became healthy.
• Drain-loop pacing. The dispatcher paces with a relative Task.Delay and a burst cap (instead
  of a fixed timer grid) and gates its first poll on ApplicationStarted.
• Explicit capability flag. IOutboxSqlDialect.SupportsPerKeyHeadOfLineOrdering is an explicit
  declaration (with a flag-plus-SQL consistency check); PostgresOutboxSqlDialect declares it.
• AllowDegradedOrdering opt-out downgrades the PerKey fail-fast to a warning.
• Documents the custom-dialect trust boundary and the PostgreSQL prepared-transactions (2PC)
  requirement in the outbox README.

2. OrderedConsumers sample fix (fix(samples): …)

Root cause: the OrderedConsumers consumer persists a ProcessedRecord through its own
DbContext inside the transactional outbox middleware's TransactionScope. That second database
connection makes the scope escalate to a two-phase (prepared) commit, which PostgreSQL rejects by
default (max_prepared_transactions=0, SqlState 55000). Every message was retried and
dead-lettered, and no record was written — pre-existing, independent of the hardening above.

Fix:

• AppHost starts PostgreSQL with -c max_prepared_transactions=100.
• The single-sample README command is corrected (it had the wrong password and created no matching
  database) and gains the prepared-transactions flag, matching the samples' default connection string.
• The 2PC requirement is documented at the consumer's DbContext registration.

Verification

• Unit: 2039 passing; Contract (public API + layer rules): 36 passing.
• Outbox PerKey full-circuit E2E (real PostgreSQL + RabbitMQ) passing.
• All three sample smoke E2E tests passing (OrderedConsumers, CompetingResponders,
  ConsumerRoutingKeys). Before the fix OrderedConsumers dead-lettered all 20 messages; after it,
  the SAC endpoint records 15 healthy + 4 poison-resume per run and only the poison head is parked.
• Standalone run reproduced and confirmed the fix verbatim against the sample defaults.