Offer an opt-in Gmail repeat-delivery guard before page creation

[garrytan]

Moved from #7210, opened by @dyana1lyons-ai on 2026-10-21. Feature requests now live in Discussions > Ideas.

---

Two Gmail threads can carry the same delivered message under different thread IDs. Page identity by thread ID then allows both pages to materialize, leaving duplicate search results until a later cleanup.

Generic reproduction: construct two synthetic one-message thread responses with different thread IDs and the same RFC Message-ID. Process both in a source sweep, then repeat with the matching first page already persisted. Current thread-based materialization has no cross-thread delivery guard before the second page write.

Request: an opt-in, source/account-scoped repeat-delivery guard using stable message identity before publication, including pages accepted earlier in the same sweep. Preserve a thread's own update and any thread with a genuine reply. Record enough content-free identity to make retries deterministic.

Acceptance: exact duplicate RFC IDs produce one page, distinct messages and replies remain, two accounts/sources cannot suppress one another, and queued/pending writes remain crash-safe. Content/time-window heuristics can incorrectly merge distinct messages, so those require a separate explicit policy; no installation-specific canary exception should enter upstream code.

Inspected upstream source: src/core/google/google-source.ts, src/core/google/sweep-shared.ts, src/core/google/google-render.ts.

Baseline: upstream master ca965f7a7cd73d34874219e91deb63099a67a6c4 (2026-10-21 UTC). Reports distinguish source inspection from executed synthetic tests; no live brain data is attached.