Dedupe duplicated conversation participants instead of quarantining the snapshot

[MaxGhenis]

What

Google conversation snapshots can list the same participant identity twice. Live occurrence 2026-08-01 ~04:54 ET: a burst of 8 conversation snapshots arrived on google-primary; 3 of them (revisions of 3 group threads) carried the account's own number twice in the roster and were quarantined by refreshConversation's duplicate-identity check. Their roster/title updates were silently dropped, and every future revision of those groups would quarantine the same way.

Diagnosed by replaying the live inbox frames (from a read-only copy of the v2 store) through the real worker apply path: exact error conversation participant identity "+1650…" is duplicated on exactly the 3 quarantined frames; all 8 apply cleanly with this fix. No messages were involved — conversation metadata only.

The fix

Identical natural key (kind + canonical) means identical identity, so the second entry can only be a duplicate — keep the first, log a warning, apply the snapshot. Quarantining the whole snapshot over a benign roster artifact permanently drops metadata the next revision won't restore.

Verification

• New regression test TestWorkerConversationSnapshotDedupesDuplicateParticipants replays the duplicated-roster shape through the worker-path harness: snapshot applies, 2 participants after dedupe, first occurrence's display name kept.
• GOWORK=off go test ./... green.
• The 8 live frames (including the 3 quarantined) all apply under this change; unfixed main reproduces the 3 quarantines.

Notes

• The error path had no test coverage before this.
• Quarantined frames are terminal today (marked processed, never re-driven). A maintenance re-drive for previously quarantined frames is a possible follow-up; the next Google snapshot revision of each group will repopulate the metadata anyway once this deploys.

🤖 Generated with Claude Code

[MaxGhenis]

Addressed Sol's review (adversarial, gpt-5.6-sol ultra):

1. Conflicting Role/Active duplicates now refuse the snapshot — dedupe only accepts state-agreeing duplicates. Live evidence drove the rule: the three quarantined frames' duplicate entries differ only in IsSelf (Google lists the account once as the self entry, once as a plain member; role/active identical), so IsSelf is OR-merged (same semantics as ensureIdentity) rather than treated as conflict — otherwise the fix would not fix the live frames.
2. Warning bounded: one aggregated line per snapshot (deduplicated=N), not one per duplicate.
3. Tests pin the full contract: both entry orders (IsSelf surfaces on the kept identity either way), kept row role/active, first-occurrence display name, and a conflicting-duplicate case asserting quarantine classification through processRecordResult.

All 8 live frames (including the 3 quarantined) still apply under the revised rule; GOWORK=off go test ./... green.