Add opt-in outbox and inbox retention sweeps

[Vulthil]

Summary

Opt-in retention so the outbox and inbox tables don't grow unbounded. Follows #226, #232, #235 (merged).

A single opt-in background sweep per concern periodically deletes terminal rows older than a window, via a store-level DeleteProcessedAsync seam. Same mechanism for relational and Cosmos — no TTL (a Cosmos container TTL can't tell a pending outbox row from a relayed one, and could expire an undelivered message). No breaking changes: IOutboxStore / IIdempotencyStore are untouched; the delete lives on new IOutboxRetentionStore / IInboxRetentionStore the EF Core stores also implement. There is no Enabled flag — registering the sweep is the opt-in.

Outbox (Vulthil.SharedKernel.Outbox)

• AddOutboxRetention(...) + OutboxRetentionOptions (RetentionPeriod 7d, SweepInterval 1h, BatchSize 1000).
• EntityFrameworkOutboxStore.DeleteProcessedAsync (base: materialize + RemoveRange, used by Cosmos); RelationalOutboxStore overrides with set-based ExecuteDelete. Deletes rows with ProcessedOnUtc or FailedOnUtc past the window; pending rows are never touched.

Inbox (Vulthil.Messaging.Inbox)

• AddInboxRetention(...) + InboxRetentionOptions. DeleteProcessedAsync on the relational (ExecuteDelete) and Cosmos (RemoveRange) idempotency stores. Docs warn to keep the window comfortably longer than the broker's max redelivery delay.

Samples, tests, docs

• The WebApi sample calls AddOutboxRetention() + AddInboxRetention().
• Store-level delete tests for outbox + inbox (old terminal rows go; recent and pending stay).
• Retention sections in both pattern articles + a bullet in each package doc.

Verification

Full Release build clean; retention suites pass (outbox 8/8, inbox 6/6); WebApi.Tests 8/8 with the sweeps registered.

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.