Run Yuvomi with SSO as the only way in: passwordless accounts, no login form, no password reset

[ulsklyc]

Split out of #654, where the switch in the title (OIDC_ALLOW_SIGNUP, shipped in v2.39.0) is done but three further wishes from @Kyrodan are not. They belong together because each one is a half-measure without the others.

Today Yuvomi always keeps a second way in. Even with SSO configured and account creation switched off, the login form stays, password reset stays, and every account carries a password hash. For a household whose identity provider is the single source of truth, that is one door too many.

1. Create an account without a password. POST /api/v1/auth/users requires a password of at least 8 characters, so an admin preparing an account for an SSO user has to invent one - and that invented password stays a working credential. Accounts provisioned through SSO already avoid this: they carry the $oidc$ sentinel instead of a hash, which no password can ever match. The admin panel needs the same option.

2. Turn built-in authentication off entirely. With SSO as the only way in, the login form should be the SSO button and nothing else - no username field, no password field.

3. Disable password reset along with it. Once nobody has a password, "forgot password" is a dead end at best. It should disappear with the form rather than stay as a route that can still send mail.

A related request from the same thread: members who never sign in but can still be assigned tasks (younger children, grandparents), with someone else completing tasks on their behalf. That is not possible today - every family member is a full account with a password - and point 1 is the groundwork for it, so it is worth deciding together with the rest.

Open questions before any of this gets built:

• Should turning off built-in auth be an env var like the other OIDC settings, or a setting in the admin UI? The env var keeps the whole SSO configuration in one place, but it also means a broken identity provider locks everyone out with no way back in from the app itself.
• What is the recovery path when the provider is unreachable? A break-glass admin account with a password would defeat the purpose; a documented .env change plus restart may be the honest answer.
• Does an existing account keep its password when built-in auth is switched off, or is it cleared?

Related: #654 (the shipped switch).

[ulsklyc]

Built, in #849. All three points, plus the groundwork for the fourth.

AUTH_ALLOW_PASSWORD_LOGIN=false switches off the login form, password login and password reset together. The bolt sits on the route rather than only on the login page - a rule the interface knows and the server does not is bypassed by curl.

The open questions above, decided:

• Env var, not a setting in the admin UI. The whole SSO configuration lives in the .env; a database setting would be a second source of truth for the same thing.
• Without fully configured OIDC the switch is ignored, and the server says so on startup. Otherwise a single line in the .env locks a household out of its own app with nothing to fall back on. A security switch that silently does nothing is worse than none, because the operator believes the door is shut.
• Existing passwords are left alone. Setting the variable back to true restores the form unchanged. Clearing a password is a per-account decision instead, in Settings → Administration → Family, in both directions - and switching an account back requires setting a password in the same step, so it is never left with no way in at all.
• Recovery is the documented .env change plus a restart. A break-glass admin account with a password would defeat the purpose, so there is none. /setup stays untouched: first-time setup has to remain possible.

Accounts without a password are an explicit sso_only flag on create and update, not an inferred "no password was sent" - otherwise a forgotten field would quietly produce an account nobody can sign in to. That is also the groundwork for the related wish in this thread, members who never sign in but can still be assigned tasks.

One bug found on the way, and it predates all of this: POST /forgot-password did not know about the $oidc$ placeholder. An account provisioned purely through SSO could have a real, working password set for it via the reset flow - triggerable by anyone who knows the email address stored in Contacts. So the placeholder's promise, that no password can ever match, was reachable around. Both lookup paths are now closed, and a token issued before an account was converted no longer overtakes that decision.

Follow-up on the remaining part of #654: #848, multiple OIDC providers, where the account-per-provider question is now decided.