Respect ALLOW_REGISTRATION in the public signup UI

[atk0309]

Summary

ALLOW_REGISTRATION=false already blocks public signup at the backend, but the frontend still offers registration and lets visitors complete the form before receiving a 403.

This PR exposes the existing setting as allow_registration in GET /api/config and makes the public registration UI reflect it. It is based on current upstream develop.

Behaviour

ALLOW_REGISTRATION=true

• Existing public signup links, registration form, and monthly/yearly plan selection remain available.

ALLOW_REGISTRATION=false

• The landing hero and all four pricing CTAs lead to Sign in; the login page's Register link is hidden.
• /register shows the existing localized closed-registration message and a clear Sign in action.
• Any nonempty ?invite=... still opens the existing form. The frontend neither validates nor consumes the token; the backend remains authoritative.
• Terms/Privacy return links lead ordinary visitors to Sign in and preserve supplied invites when returning to registration.

Authenticated dashboard links and checkout behaviour are unchanged.

Why

This makes the existing invite-only setting usable for private/self-hosted installations, families, schools and classes, controlled communities, and internal deployments. Visitors can understand the access policy before entering their account details.

Implementation notes

• Registration defaults to closed until config explicitly enables it. Ordinary registration shows a loading state during the request and stays closed on failure or a missing flag. Supplied invites remain usable independently of config loading.
• Reuses existing translation keys in all ten UI locales; no new English-only copy or translation churn.
• The existing one-hour landing config cache is preserved. A code comment and the specs explain that landing CTAs can lag a flag change. The backend continues enforcing the current setting on every signup request.
• An optional reviews-fetch failure no longer discards a successful config response.
• Updates the API, platform, and frontend specs. Adds an unversioned Unreleased changelog entry, leaving release numbering to the maintainer.
• No changes to backend registration/invite enforcement, dependencies, database models, deployment configuration, or workflows.

Validation

Run locally with Python 3.14.7, Node 25.9.0, and npm 11.9.0:

• BLACK_NUM_WORKERS=1 ./scripts/format.sh — passed (Ruff, Black, ESLint autofix, Prettier). One Black worker is required by the local execution environment.
• cd backend && pytest -v — 1,417 passed, 85.86% coverage, above the 70% gate. Proxy environment variables were unset for the isolated test process.
• cd frontend && npm run lint — passed.
• cd frontend && npx tsc --noEmit — passed.
• cd frontend && npm run test:run — 585 passed across 59 files on the final run.
• git diff --check — passed.

The first full frontend run had 584 passes and one failure in the unchanged lesson-word-tooltip.test.tsx test “dismisses the word tooltip when navigating to the next exercise” (missing saveWord). Without changing that test or its implementation, the focused file passed 3/3 and the repeated full suite passed 585/585. No retries were added to the test configuration.

Coverage includes both config values; public landing/login/pricing links; registration loading and failure states; ordinary signup and plan selection; invite submission and backend rejection; legal-page invite navigation; and authenticated checkout. Backend regression tests also exercise admin-generated single-use invitations and rejection of invalid/reused tokens.

Screenshots

Public registration enabled

Tested but no screen shot.

Public registration disabled

Landing page

Registration page

Registration via invite

Tested and it works.

[artcc]

Thanks for the contribution and the thorough tests! This makes invite-only setups much clearer for users. We’ve reviewed the changes and will handle a small config-loading recovery improvement on our side. Really appreciate your work!