Remove ChiAuthBackend (5.0.0)

[robireton]

Fixes #9. Stacked on #20 (4.0.1). Merge that first, and GitHub will retarget this PR to main.

Why now

#9 was waiting for a survey of every consumer before deleting a login path. The survey is done: the only consumers are daedalus, email_service and monitor, all on chi-cetus. The other names in #9 and in this README's old "Projects using it" list were guesses, and none of those repositories mentions user_manager. All three consumers run header SSO in production, so ChiAuthBackend authenticated nobody.

What goes, and what stays

Stays: login_view's form and login.html, authenticating through Django's ModelBackend. Deleting the whole password path, as #9 first proposed, would have broken two things:

• Local development. daedalus and monitor default CHI_AUTH_USE_MIDDLEWARE to False, and monitor's README says that's how you sign in locally.
• The break-glass sign-in. email_service's README documents /admin/login/ as the way in for a local superuser.

Goes, because nothing else read it:

• authentication_backends.py and its 16 tests
• the settings CHI_AUTH_API_ACCESS_TOKEN, CHI_AUTH_CHECK_SYSTEMS, CHI_AUTH_TIMEOUT and UC_PASSWORD_MANAGER_URL
• the ACCOUNT_LOOKUP_URL and allow_chi_auth_login context variables. No consumer template uses them.
• in login.html, the "sign in with your UC/CHI credentials" hint and the two password-help links
• the requests dependency. daedalus and monitor import requests and already declare it; email_service doesn't import it.

New checks for the upgrade

• user_manager.E003 fires when AUTHENTICATION_BACKENDS still lists ChiAuthBackend. Django only imports a backend at sign-in, so without this check a missed line fails every login, /admin/login/ included, after a deploy that looked healthy. I confirmed it: authenticate() raises ModuleNotFoundError, and manage.py migrate exits 1 without applying anything.
• user_manager.W009 names any of the three removed settings that is still set. All three consumers set them today.

⚠️ E003 only stops a deploy whose entrypoint runs set -e. daedalus's and monitor's do. email_service's doesn't: a failed migrate there falls through to gunicorn. The upgrade note says to check it by hand, and the missing set -e is already recorded as drift in chi-platform convergence.md §5.

Consumer work

Each consumer needs one change alongside its pin bump: remove one line from AUTHENTICATION_BACKENDS, and delete the three settings from settings.py, example.settings.env and the deployed settings.env. All three are still on v3.2.0, so this goes on top of the 4.0 bumps already filed (daedalus#99, email_service#44, monitor#44). Doing both in one pass means each consumer gets touched once.

Verification

• runtests.py: 97 tests pass (was 110: −16 backend tests, +3 checks, +1 settings test, and the context-processor tests rewritten). The login tests run against ModelBackend alone.
• ruff check and ruff format --check are clean.
• chi-platform/audit.sh user_manager: ✓ 18 checks.
• A settings module that still lists the backend and sets CHI_AUTH_TIMEOUT gets E003 and W009 from migrate and runserver.

🤖 Generated with Claude Code