feat: add transport-independent event ingestion

[giscebot]

Summary

This pull request implements Phase 0 of #191:

• add durable per-transport receipts and canonical GitHub event identities
• route IMAP notifications through the common transactional ingestor
• deduplicate proven cross-source equivalents while falling back to source identity when uncertain
• document the IMAP/webhook trade-offs and gradual rollout

Scope

This is the internal ingestion refactor only. It does not close #191: the webhook shadow, dual-ingest canary, primary-webhook rollout, and stable IMAP fallback remain pending in later phases.

Safety and compatibility

• work_key coalescing remains unchanged and separate from event identity
• no webhook endpoint or external behavior is enabled in this phase
• only hashes and minimal audit metadata are persisted; raw payloads are not retained
• schema changes use idempotent CREATE TABLE/INDEX IF NOT EXISTS

Tests

• pytest -q — 371 passed, 1 dependency deprecation warning

Implements Phase 0 of #191

[ecarreras]

@giscebot modifica la descripció ja que aquesta pull-request no tanca la issue sino que es només la FASE 0

[giscebot]

Descripció actualitzada: ara identifica explícitament aquest PR com la Fase 0 de #191, elimina el tancament automàtic de la issue i deixa enumerades les fases webhook que continuen pendents. No hi ha canvis de codi.

[pilipilisbot]

Reviewed the transport-independent ingestion refactor end to end. The new receipt/event split looks consistent with the existing queue contract: IMAP now goes through the common transactional path before advancing the high-water mark, source receipts are idempotent, canonical event keys deduplicate proven cross-transport equivalents, and work_key coalescing remains separate from event identity.

I also checked the SQLite schema path for existing databases and the added queue/reader coverage. CI is green, and I ran the full suite locally in a temporary venv: 371 passed, 1 warning (the existing Starlette/httpx deprecation warning).

Residual note, not blocking for Phase 0: the canonical key intentionally treats the same GitHub comment/review object as one event, so a future webhook implementation should be explicit about how edited-comment deliveries are classified if edits are ever meant to retrigger work.

[giscebot]

Comprobación post-merge: el commit de merge 4aa3e91 ya está en main y los tres checks quedaron verdes.

Hay un efecto pendiente: #191 se cerró automáticamente al fusionar este PR, aunque la descripción corregida indica que solo implementa la Fase 0 y que las fases webhook siguen pendientes. Conviene reabrir #191 para conservar el seguimiento de esas fases. No la reabro desde esta ejecución porque está limitada a revisión (review_only).