password-reset: a confirmed e-mail, then a link to reset the password

Agreed by the owner on 2026-10-13 ("the e-mail must be confirmed");
notifications to an unconfirmed address settled on 2026-10-17: "Без
подтверждения слать". Mockups 2f5f5b2, route guard b7bbb2c, panel guard
0774da2.

Migration 0013: users.email_confirmed_at ('' for every address saved
before it) and user_links - the SHA-256 of a link's token, its user,
purpose (confirm, reset), address, created and expiry. A changed address
loses its mark (keepConfirmed, in UpdateUser and SaveUser).

internal/web/auth/links.go. A link is 256 bits from crypto/rand, mailed as
https://SELFPOST_HOSTNAME/... - never the request's Host. Confirmation:
24 h, sent when an address is saved (Account, or the global role's user
form) and by Account's Send the link again; its page /confirm/<token> has
a button (a GET changes nothing) and confirms only for a session of its
own account. Reset: /login/reset asks for a username and answers the same
for every name (the sign-in page, "If that account has a confirmed e-mail,
the link is on its way"), mailing after the answer; only a confirmed
address gets one, none within ten minutes of the last, five links an hour
per account, five requests in 15 minutes per client address;
/login/reset/<token> (30 min) sets the password with the link taken in
the same transaction that checks the address again
(store.TakeResetLink), then ends every session. Changing the e-mail on
Account asks for the current password. A password set on Account or the
user form removes the reset links; a restore removes every link; the stop
waits for links being mailed (Server.Drain); a rejected request's log line
hides a link's token (loggedPath).

Reviewed for security before the commit (2026-10-17): no high; two
medium and five low, all fixed here - confirming needs the account's
session and the mail does not name the account (a mistyped address was a
takeover); a reset request neither replaces the links already sent nor
spends the account's quota inside ten minutes; take-and-set atomic; the
confirmation mail sent after the answer; the stop waits for mail; a
restore deletes the links; the token kept out of the log.

Tests: store TestUserLinks, TestUserLinkTakenOnce, TestEmailConfirmation,
TestTakeResetLink; auth TestResetSendsALinkOnlyToAConfirmedAddress,
TestResetLinkSetsThePasswordOnce, TestResetLinkDiesWithTheAddress,
TestResetRequestsAreLimited, TestResetRequestsAreSpaced, TestConfirmLink,
TestLinkPathsWithoutAToken; handlers TestAccountEmailIsConfirmedByItsLink,
TestUserFormSendsANewAddressItsLink; web TestLoggedPathHidesTokens; the
view's pages and fixtures; e2e password_reset_by_e_mail runs it through
the sink (and checks a link from before the restore is dead). go vet +
go test (26 packages) and make e2e on the test server for this tree.

Docs: guide § Account, security.md (the bullet and what ends sessions),
architecture (routes), schema-migrations (row 13, users, user_links),
help #account (word for word with the mockup), roadmap row done,
CHANGELOG [Unreleased].

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/guide.md

@@ -558,14 +558,36 @@ readings, numbered in the order of what stops mail first:
 ### Account
 
 **Account** (`/account`, every role) is the signed-in user's own: **Profile**
-(username and e-mail) and **Password**. Saving the profile does not ask for the
-password; changing the password asks for the current one and is rate-limited
-like a sign-in. The e-mail is the user's own address: it is where the panel
+(username and e-mail) and **Password**. Changing the username or the
+notifications switch does not ask for the password; changing the e-mail does,
+and so does changing the password, both on the limit of a sign-in's guesses
+(ten in 15 minutes per user). The e-mail is the user's own address: it is where the panel
 sends [notifications](#notifications) while *Send me notifications* is ticked
 beside it, and what a domain's *Use my e-mail* button fills in (see
 [Domain-level DNS](#domain-level-dns-spf-dkim-dmarc)). Application SASL logins
 are separate and are not changed here.
 
+**A confirmed e-mail and a forgotten password.** A new address - saved under
+Account, or typed for a user by the global role on the user form - is sent a
+link that confirms it (`https://<SELFPOST_HOSTNAME>/confirm/…`), which works
+once, for 24 hours, opened in a browser signed in as that account; its page
+has a button, and only the button confirms. The mail does not name the
+account, so a mistyped address cannot be confirmed by whoever reads it.
+Account tags the address *confirmed* or *not confirmed* and, while it is not,
+offers *Send the link again* (at most five links an hour to one address).
+Notifications go to the address either way. Only a confirmed address can be
+sent a reset link: *Forgot your password?* on the sign-in page asks for the
+username and always answers the same - whether the name exists, and whether
+its address is confirmed, is not said; another link is not sent within ten
+minutes of the last - and the link
+(`https://<SELFPOST_HOSTNAME>/login/reset/…`) works once, for 30 minutes, and
+only while the account's address is still the one it was sent to. Setting the
+new password signs every session of the account out. The links name the
+server by `SELFPOST_HOSTNAME`, so the panel must be served at that name. An
+account without a confirmed address recovers as before: the global role sets
+a new password on the user form, and the only global user from the container
+(see [Users](#users)).
+
 ### Settings
 
 **Server › Settings** (`/server/settings`, global role) holds what is true for