feat: auto-enroll newly registered users in Library Assistant

[dcschreiber]

(Claude and Codex writing on Daniel's behalf)

What

Auto-enrolls every newly registered user in the Library Assistant experiment. Story: https://app.shortcut.com/sefaria/story/46170

Product direction: opt-in stops being a user choice for new registrations; the account settings toggle remains the opt-out.

How

process_register_form is the shared registration path for both the web form and the mobile/JWT API. It calls the existing experiment setter while the registration transaction is active, so the required UserExperimentSettings row remains transactional and the Mongo profile is updated in the same lifecycle step.

The setter now has an opt-in dispatch_webhook_on_commit mode. Registration uses it to defer only the irreversible CRM dispatch until the PostgreSQL user transaction commits. Other existing setter callers retain their current immediate-dispatch behavior.

This means:

• failed registration cannot produce a ghost CRM enrollment
• enrollment failure still prevents the user transaction from committing
• an external queue failure cannot roll back a successfully committed user

Both #3559 and #3560 use the same module-level reader_models import, so the two PRs merge cleanly in either order.

Why enabling at registration makes LA open automatically

The widget in ReaderApp.jsx renders <lc-chatbot ... default-open={true}> once the user is enabled. A brand-new user has no stored widget state to override that default, so the assistant opens automatically on the first library page load.

How tested

reader/tests/register_auto_enroll_test.py covers:

• web registration creates enrollment before the commit callback, then dispatches CRM exactly once afterward
• web registration still logs the user in
• API/JWT registration enrolls too
• invalid registration creates no user, enrollment, or webhook

Final related run: 16 passed across registration and experiment-setter/admin coverage.

[gitvelocity-reviewer]

📊 Code Quality Score: 14/100

34 × 0.4 = 13.6 → 14

Category	Score	Factors
🔭 Scope	6/20	Two files, single subsystem (registration flow), one new behavior added to core registration path
🏗️ Architecture	4/20	Cross-module call to private function (_set_user_experiments); deferred import suggests possible circular dependency; minor coupling concern between sefaria.views and reader.models
⚙️ Implementation	5/20	Simple 4-line production change; test setup has moderate complexity with multi-DB support, UUID-based isolation, and multi-layer mock orchestration
⚠️ Risk	7/20	Affects all new user registrations globally; no feature flag for gradual rollout; behavioral change to core registration flow; no rollback mechanism documented
✅ Quality	11/15	4 meaningful test cases covering web form, API, invalid registration, and session login; proper mocking of external dependencies; minor tearDown incompleteness (missing user.delete()); vague experiment assertion
🔒 Perf / Security	1/5	No specific performance or security considerations required for this change; basic input validation inherited from existing registration flow

Was this score accurate? 👍 Yes · 👎 No

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