[CRITICAL][Migration] Audit existing users and legacy authentication/billing state before production launch

Goal

Before Tracker becomes a live paid product, perform a one-time migration/readiness audit for accounts created before the current authentication and billing systems.

The migration must be explicit and safe. Do not modify existing users blindly.

User categories

1. Google-only users

• Preserve Google authentication.
• No password is required unless the user chooses to add one.
• Do not change account identity or session behavior.

2. Legacy 4-digit PIN users

These users must be migrated to the new password system tracked in #49.

• Do not silently turn the PIN into a password.
• Require secure authenticated password setup/migration.
• Invalidate the legacy PIN after successful migration.
• Preserve the account and user data.
• Prevent account takeover through the migration flow.

3. Existing Free users

• Keep Free entitlements.
• Do not grant Pro because the account predates billing.
• Preserve all existing user data.

4. Existing Test Mode Pro/subscription records

• Treat Test Mode billing as test data, not production entitlement.
• Ensure Test Mode Razorpay customer/subscription/plan/offer IDs cannot grant production Pro.
• Archive/isolate/mark these records as appropriate before Live Mode.

5. Any legacy premium/manual access

Find and explicitly document any users whose historical state implies premium access without a current provider-backed subscription.
Do not guess. Define a deliberate migration policy before launch if such accounts exist.

Required audit

Produce a migration report containing counts for:

• Google-only accounts;
• legacy PIN accounts;
• password accounts;
• accounts with no billing record;
• Free subscriptions/state;
• active Test Mode subscriptions;
• historical/cancelled subscriptions;
• any legacy/manual premium state.

The report must not expose passwords, password hashes, payment secrets, or sensitive user content.

Safety

• Take a database backup before destructive migration.
• Make migrations idempotent.
• Never delete user data as part of authentication/billing migration.
• Do not reset passwords automatically.
• Do not grant paid access automatically unless the migration rule explicitly proves why it is valid.
• Keep an audit trail for migration changes.

Acceptance criteria

• Every existing account falls into a known migration category.
• Legacy PIN users have a safe password migration path.
• Test Mode billing records cannot affect production entitlements.
• Existing Free users remain Free.
• Google users continue to work.
• No user content is lost.
• Migration is repeatable/idempotent and tested before production execution.

No files, tests, or entry points are named. Start by mapping the existing authentication, billing, subscription, and account data represented in the repository, then define the migration categories and report inputs. Done means the safety, idempotency, audit-trail, entitlement-isolation, and password-migration criteria are verified before production execution.