Let people change their own password, and operators reset a lost one

The account system shipped without either, which made the first forgotten
password an unanswerable support request.

Changing it requires the current one. A session is what an attacker gets from
a borrowed laptop or a stolen cookie; the password is what they do not have,
and without the check the first thing they would do is take the account.

Every session is closed, including the browser doing the changing — leaving
the others open would mean a password change does nothing about the reason
someone is changing it. A new session is then opened for the browser in front
of us, so the person who just proved their password is not thrown back to the
sign-in page. That response also carries a new CSRF cookie, so the forms it
renders take the new token rather than the one the request arrived with; there
is a test that posts a form from that exact page.

Guessing the current password is bounded the same way sign-in is, because
someone holding a stolen session should not get unlimited attempts at the
password that would let them keep it.

There is no self-service reset: this gateway sends no email, and a reset link
with nowhere to send it is not a reset. `llmgw users reset-password` is the
operator's answer, and it closes their sessions too — if someone lost their
password, the reason might be that somebody else has it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/onboarding.md

@@ -218,11 +218,29 @@ its cache expires — `auth.cache_ttl`, 30 seconds by default. That is the price
 keeping the database off the request path, and it is the number to lower if you
 need revocation to bite faster.
 
+## Passwords
+
+People change their own from `/profile`. It asks for the current one — a session
+is what someone gets from a borrowed laptop, and the password is what they do not
+have — and it signs every other browser out, which is the point if they are
+changing it because something went wrong.
+
+There is no self-service reset, because this gateway sends no email and a reset
+link with nowhere to send it is not a reset. When someone loses theirs:
+
+```
+llmgw users reset-password usr-k4mq… --password "a temporary passphrase" --store …
+```
+
+Tell them out of band and have them change it from their profile. Their sessions
+are closed — if they lost the password, the reason might be that someone else has
+it. Their API keys keep working; those are separate credentials.
+
 ## What this does not do
 
-- **No email.** No approval notice, no password reset, no address verification.
-  Someone who forgets their password needs you, and there is no command for that
-  yet — `llmgw users create` is the workaround, which changes the address.
+- **No email.** No approval notice, no self-service password reset, no address
+  verification. The loop is manual on purpose at this size; if it stops being
+  the right size, that is the thing to automate.
 - **No SSO.** Accounts are local, with local passwords.
 - **No roles.** Every approved account can do the same things: make its own keys
   and nothing else. Administration is the CLI, and having a shell here is what