chore(sc-46275): drop the UserExperimentSettings table (phase 4)

[dcschreiber]

(Claude writing on Daniel's behalf)

Phase 4 of sc-46240 — sub-task sc-46275. The deploy after Phase 3.

Stacked on #3573 (Phase 3), which is itself stacked on #3572. Rebase onto master as each lands.

• reader/migrations/0002 deletes the model and its table; reader/models.py is now empty.
• scripts/migrations/archive_user_experiment_settings.py dumps the rows to CSV first — reversing a DeleteModel recreates the schema, not the data. It reads the table with raw SQL rather than the model this PR deletes, so it must be run before the deploy applies the migration.
• The Phase 2 flip scripts are removed: the forward migration sourced its cohorts from this table and can no longer run, and its rollback window closed in Phase 3. What they did survives in the Mongo archive collection they wrote (library_assistant_migration_archive).

Deploy-day order

1. Run python scripts/migrations/archive_user_experiment_settings.py against production and keep the CSV.
2. Deploy (the migration applies).

🤖 Generated with Claude Code

[gitvelocity-reviewer]

📊 Code Quality Score: 14/100

Base Score 34 × ESF 0.4 = 13.6, rounded to 14

Category	Score	Factors
🔭 Scope	7/20	4 files across migrations, models, and scripts; single subsystem (reader app); removes a model and associated operational scripts; no new public APIs or external integrations
🏗️ Architecture	6/20	Removes a model from the system (architectural cleanup); no new patterns or dependencies introduced; the delete+recreate migration pair adds minor migration graph complexity
⚙️ Implementation	5/20	Migration boilerplate is straightforward Django; archive script uses intentional raw SQL to avoid model dependency; deleted scripts had moderate complexity (batch writes, MongoDB, idempotency) that is now gone
⚠️ Risk	9/20	Database table drop with data loss risk if archive script not run first; 0002+0003 migration pair creates acknowledged technical debt and migration state complexity; no automated enforcement of operational sequencing; acknowledged TODO to squash before merge
✅ Quality	6/15	Excellent inline documentation in migrations and archive script; no tests for archive script or migrations; acknowledged pre-merge TODO embedded in production migration code; missing DJANGO_SETTINGS_MODULE guidance in usage docs
🔒 Perf / Security	1/5	No notable performance or security considerations; raw SQL uses parameterized-style query with no user input; LEFT JOIN handles orphaned rows correctly

Was this score accurate? 👍 Yes · 👎 No

How this was scored →

_{Scored by GitVelocity · How are scores calculated?}

[dcschreiber]

(Claude writing on Daniel's behalf) Closed: with the experiments framework staying in the codebase (see #3579), the model — and therefore its table — stays. Phase 4 is now a script run that archives and deletes the rows and unsets profiles.experiments (scripts/migrations/wipe_experiments_data.py, shipped in #3579). No schema change.