Spike: Duplicate User Records & Mismatched Contributor Identity

**Background**
During refinement of the Contribution Bio ticket (#2452), the team identified a known issue where the same real-world contributor can appear as multiple distinct user records in the database. This happens when a contributor has used different email addresses or name variants across commits over time, and those identities haven't been linked to a single account.
The result is that contribution counts and library associations get split across records , a contributor may appear to have fewer contributions than they actually do, or appear multiple times under different names.
A separate but related issue was also flagged: placeholder or example emails may be getting created in the system for unmatched names. This is messy and needs investigation.
Both issues are deferred from the Contribution Bio happy path. This spike scopes and documents the problem before any fix is built.

---

**Goal**
Understand the shape and scale of the duplicate identity problem so the team can make an informed decision on whether and how to address it in v3.
This is a discovery spike, not an implementation ticket. The output is a written findings doc, not shipped code.

---

**Questions to answer**

- How common is this? Roughly how many user records in the current DB appear to represent the same person under different emails or name variants?
- How do placeholder/example emails get created? What triggers their creation, how many exist, and what records are affected?
- What does the existing merge/link path look like? Is there any current mechanism for linking multiple commit emails to a single account, and how far does it get us?
- What are the cascade effects of merging records? Libraries, posts, achievements, badges — what breaks or needs backfilling if two records are merged?
- What is the manual admin path for edge cases where a user no longer controls an old email address?

---

**Known context going in**

- The v3 profile flow will allow users to add their own commit emails, which covers the common case going forward (#2440)
- Rob's position (confirmed in demo): once a commit email is verified and bound, it cannot be deleted due to cascading effects on historical library/contributor records
- Pending emails are safe to remove; verified ones are not
- Edge cases where a user no longer controls an old email will need a manual admin handling path

---

**Out of scope for this spike**

- Implementing a merge/deduplication feature
- Changes to the Contribution Bio rendering logic
- Automated deduplication tooling

**Output expected**
- A short findings doc (can live as a comment on this ticket or in Notion) covering:
- Rough scale of the problem (order of magnitude, not precise count)
- Root cause of placeholder/example email creation
- Recommended approach: self-serve via commit email linking, admin tooling, or a combination
- Any blockers or dependencies (e.g. data migrations, admin UI work) that would need scoping before a fix ticket is written

No files or tests are named. Start by tracing the existing user, commit-email, placeholder-email, and merge/link records described in the ticket, then document the problem's scale, causes, cascade effects, and recommended path. Done means a short findings document covers the requested questions and blockers.

Written by the indexing model from the issue text.