D3.1 phase 5: Rename CustomUser to User (RenameModel, AUTH_USER_MODEL)

Part of the D3.1 umbrella (#334): phase 5 of 6. P7 step 2's model rename, isolated as its own small, final-schema-shape step.

Normative sources

Goal

migrations.RenameModel("CustomUser", "User") and AlterModelTable to accounts_user, AUTH_USER_MODEL updated to "accounts.User" in the same change. End state: model accounts.User, table accounts_user, all rows preserved, zero behavior change.

Scope

• The rename migration, using the operation sequence makemigrations generates.
• AUTH_USER_MODEL = "accounts.User" in settings, landed atomically with the migration (Django cannot resolve the old model name after the rename — see the linked owner decision).
• Fix every now-broken CustomUser import across the codebase.
• accounts/identity_inventory.py literal fixes (do not skip — these live in string literals, so neither the import rewrite nor an attribute-access grep catches them):
  • ACCOUNT_MANY_TO_MANY_RELATIONS: "owner_model": "accounts.CustomUser", the "through_table" values accounts_customuser_groups/accounts_customuser_user_permissions (implicit m2m through tables rename with the model), "user_field": "customuser" (the reverse accessor becomes user).
  • ACCOUNT_RELATIONS's first entries: "accounts.CustomUser_groups"/"customuser".
  • By contrast, accounts_customuser literals in accounts/services/cmp_learner_import.py and CmpLearnerImportProgress.table values name the CMP export's source tables, not the live table, and must NOT be touched.
• Verify current main for any further CustomUser-literal or accounts.CustomUser model-label string added since #334's original grooming (for example in accounts/tests/test_identity_quarantine_revocation.py, accounts/tests/test_username_allocation.py, and the management_auth/management_api modules touched by that same BE-08 fix) before finishing — this table is a floor, not the full inventory.

Non-goals

• No get_user_model() idiom sweep beyond fixing imports the rename itself breaks.
• No django_migrations cleanup, no squashed-migration --fake, no P5 relabel work.
• No AISL field additions (phase 6).
• No login-behavior, allauth-adapter, or permission-logic change beyond rename fallout.

Dependencies

• Depends on: #393 (the contract phase must land first — renaming while stale duplicate fields still exist on CustomUser risks the rename migration and the field-removal migration racing on the same table during a rebase).
• Blocks: D3.2 and C3.7 (per #334), and #395 (kept last to match the original plan's stated ordering; phase 6 is otherwise independent and could reorder if the owner prefers).

Acceptance criteria

Django and integration

• make django-check / make migrations-check pass.
• make test (full suite) passes.
• get_user_model() resolves to accounts.User with db_table accounts_user.
• Email login authenticates through the Django test client (login, session, member page 200); the dark-mode toggle endpoint still works end to end through learner_profile.
• grep -rn "CustomUser\|accounts_customuser" --include=*.py . | grep -v migrations | grep -v .tmp shows only the CMP-import source-table literals and any deliberately preserved docstring/comment references; the PR body records this grep's output.
• manage.py migrate applies cleanly end to end on a fresh database.

Browser

• make test-playwright-core passes.
• [HUMAN] After the development deploy: login with an existing development account works and the dark-mode toggle persists.

Repository and operations

• Versioned verification plan per _docs/ci/change-selective-ci.md recorded in the engineer handoff.

Confirm dependency #393, then read the current account model, migration history, settings, and accounts/identity_inventory.py, including the listed literal values. Run make django-check, make migrations-check, and the focused identity tests before the full suite and browser checks. Done means the rename preserves rows, resolves accounts.User with accounts_user, fixes import and literal fallout, and satisfies the stated grep and migration checks.