Define legacy website data migration scope for events and deck data

Sources: Featurebase posts from David T / thodl15@gmail.com:

• 6a209ff3830d0ac0f9009e3c (Migrate existing store events): "There are multiple prior events missing from the old website, you need to migrate those over too."
• 6a209f28a035a111ad254e00 (Handle DB migration from old website): "There’s existing deck data hanging out in some old schema in your prior website, you really ought to migrate that over as part of the initial rollout"

PM triage:

• Problem: the rollout may strand existing user-visible event history and deck data if legacy website data is not migrated or intentionally excluded.
• Evidence: two related Featurebase reports from the same submitter; no specific store, event, player, deck IDs, or rollout owner named yet.
• Current workaround: unclear; users may perceive missing historical data as data loss.
• Product decision needed: define which legacy event/deck data must migrate for v1, what can remain archival-only, and who owns validation before rollout.
• 90/10 candidate: identify the smallest user-visible historical dataset required for launch continuity, migrate that path, and document any intentionally unsupported legacy data.

Needs product scoping/decision before implementation:

• Which old website/schema is the source of truth?
• Which data types are launch-blocking vs nice-to-have?
• Concrete examples of missing stores/events/decks to validate against.