feat(storage): EfMessageStore — SQL claim (UPDATE…RETURNING) + idempotent fan-out (S2 of #37)

[williamdewitt]

What

Sub-task 2 of 3 for #37 (durable SQLite store), under M2 epic #8. Implements the internal IMessageStore on EF Core / SQLite, mirroring the in-memory store's semantics exactly.

The claim path (the interesting bit)

ClaimDueAsync pushes the claim into one atomic statement:

UPDATE messages SET owner = $owner, lease_until = $lease_until
 WHERE id IN (SELECT id FROM messages
               WHERE status = $pending AND next_attempt_at <= $now
                 AND (owner IS NULL OR lease_until < $now)
               ORDER BY next_attempt_at LIMIT $batch)
RETURNING ...;

SQLite serializes writers, so a competing dispatcher's identical statement runs against the already-claimed state and its WHERE excludes those rows — no double-claim, no SKIP LOCKED needed (that's the Postgres story, #38). Due = pending + next attempt arrived + (unowned or lease lapsed); lease_until < now is strict, so a lease is still held at the exact expiry instant.

The rest

• AddAsync — idempotent on (event_id, endpoint_id) via INSERT … ON CONFLICT DO NOTHING; the rows-affected sum is the count actually inserted.
• MarkDelivered / Reschedule / DeadLetter — EF ExecuteUpdateAsync (set-based, no load).
• A fresh context + connection per operation (DbContext isn't thread-safe) so the store is safe under concurrent dispatchers; deps are IDbContextFactory + TimeProvider.
• Core exposes its internal resource-access contracts to the provider via InternalsVisibleTo.

Verification

• 175 tests green on net8.0 + net10.0, zero warnings. Tests mirror InMemoryMessageStoreTests against a real SQLite file: claim/lease/crash-recovery, idempotent fan-out, batch order, the exact-expiry boundary, no-double-claim across 8 concurrent workers over 200 messages, constructor guards, full-message round-trip.
• Mutation: EfMessageStore.cs = 100% locally (dotnet stryker --project Caliber.Webhooks.EntityFrameworkCore).

Follow-up (called out, not in this PR)

The EF provider isn't in the CI Stryker scope yet (config is core-only). Wiring it in — together with covering the #45 config files (EndpointConfiguration/WebhookMessageConfiguration, currently 0%, exercised once #47's endpoint round-trip tests land) — is the next quality-gate step so the provider lands in the mutation gate with a green full score.

risk:core — human review + merge. Closes #46.