Remove the library-authentication feature (staged) — untangle it from the core login machinery it shares an app with

[rdhyee]

Goal

Remove the library-authentication feature (log in / gate access via a Library — IP ranges, card patterns, library admin) that Eric approved retiring. This issue scopes it, because the naive "delete the libraryauth app" is not what's needed.

Key finding — libraryauth holds the site's core login, not just library auth

The regluit.libraryauth app is misnamed for its current role: alongside the library feature it contains the main authentication machinery used site-wide. Deleting the app would break all login. The pieces split into two groups:

A. Shared / core auth — MUST be kept (relocate, don't delete)

Symbol	File	Used by
superlogin, login_user, Authenticator	libraryauth/views.py	frontend/views/__init__.py:122 — the main site login
UserNamePass	libraryauth/forms.py	frontend/views/__init__.py:121 — main login form
selective_social_user, chop_username, selectively_associate_by_email, deliver_extra_data	libraryauth/auth.py	SOCIAL_AUTH_PIPELINE (settings/common.py:320-348) — all social login
SocialAuthExceptionMiddlewareWithoutMessages	libraryauth/auth.py	MIDDLEWARE (settings/common.py:148)
pic_storage_url, AVATARS	libraryauth/auth.py	core/models/__init__.py:40, core/management/commands/fix_avatars.py — avatars

B. Library-specific — the actual removal target

• Models (libraryauth/models.py): Library, IP / IPAddressFormField / IPAddressModelField, Block, CardPattern, LibraryUser, EmailPattern, BadUsernamePattern
• Views: join_library, library, UpdateLibraryView, login_as_library, library_users, library_admin, etc.
• URLs (libraryauth/urls.py): the ^libraryauth/<id>/… routes
• Templates: libraryauth/templates/libraryauth/*
• External consumers to update: Library is imported in core/models/__init__.py:41, frontend/forms/__init__.py:42, frontend/views/__init__.py:123; LibraryUser in core/signals.py:33; core/tests.py:1205 references the Library model.

Proposed staged plan (each a reviewable PR, validated on test.unglue.it)

1. Decouple the shared auth glue (behavior-preserving). Move group A out of libraryauth into a non-library home (e.g. core/auth.py / keep a thin module), update the settings pipeline/middleware paths and the frontend imports. No feature change; the riskiest step for login, so validate social + password login on staging before merge.
2. Remove the library UI surface. Drop the ^libraryauth/… URLs, the library views, and templates; remove Library/library imports from frontend and core (guard any is_free/access-check call sites that consulted library access).
3. Remove the library models + data. Delete Library, LibraryUser, Block, CardPattern, EmailPattern, BadUsernamePattern, IP fields; add the Django migration to drop the tables. (LibraryUser also interacts with core/signals.py — handle the signal.)
4. Settings + cleanup. Once B is gone and A is relocated, drop 'regluit.libraryauth' from INSTALLED_APPS (or shrink the app to the relocated shared bits) and remove dead templates/tests.

Risks / notes

• Auth is the blast radius. Step 1 touches the login path for every user; needs staging validation (test.unglue.it), not local-only.
• There may be access-control call sites (library-gated downloads / lib_acqs, Hold/library holds) that assume Library exists — audit those before step 2/3.
• Related but distinct: the handle_same_email_account dedup signal in libraryauth/signals.py (see libraryauth_dedup_impact.md) — decide keep/relocate as part of step 1.

Ask

Confirm the scope (remove feature B, preserve/relocate A) before the first PR lands, given step 1 rewires the core login path. PRs will be opened against master and validated on test.unglue.it.

[rdhyee]

Scope decision (Eric, 2026-07-03 meeting): remove the FRONT-END library features only — library-user auth UI, library pages, and related docs. Backend (models/data/shared auth machinery) stays in place for a later pass. This narrows the staged plan above: step 1 (relocating shared login glue) is deferred along with the backend removal; the first PR should target only the user-facing library surface (URLs/views/templates/nav links), leaving models and auth pipeline untouched.