Self-hosting: the one manual step older SQLite relays need

Relay finding F10 fixed the email-verification migration on SQLite. It
was meant to mark every existing account verified and, because SQLite
has no NOW(), marked nobody without raising an error. The fix only
reaches relays that have not run that migration yet, since a migration
runs once. The by-hand repair for the rest was written down only in a
relay commit message, which is not somewhere a self-hoster looks.

It is on the page now, under Updating. The UPDATE marks only accounts
created before the migration ran, read from the migration's own row in
_fluent_migrations, so anyone who signed up since still has to confirm
their address, and it is safe to run twice or on a relay that never
needed it.

The relay renders this page and runs the SQL exactly as printed against
a database left in the broken state, so the two cannot drift apart.

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

SELF-HOSTING.md

@@ -202,6 +202,36 @@ relay reads an older database and brings it forward. Take a dump first anyway,
 not true, and an older relay against a newer database is not a supported
 direction.
 
+### One step by hand for older SQLite relays
+
+This is for a relay on SQLite (no `FN_POSTGRES_URL`) that was already running
+before 25 September 2026. Postgres relays can skip it, and so can a SQLite relay
+first started after that date.
+
+When email verification was added, the upgrade was meant to mark every account
+that already existed as verified, so that switching verification on later
+would lock nobody out. On SQLite that step failed without an error and marked
+nobody. Nothing changes until you set `FN_EMAIL_VERIFICATION_REQUIRED`. Once
+you do, everyone who signed up before that upgrade is turned away and asked for
+a code from an email that was never sent.
+
+The relay now does this correctly, but each upgrade step runs once, and a relay
+that already ran the broken one will not run it again. Stop the relay, copy
+`relay.sqlite` somewhere safe (it is wherever `FN_DB` points, if you set it),
+open it with `sqlite3 relay.sqlite`, and run:
+
+```sql
+UPDATE users SET email_verified_at = CURRENT_TIMESTAMP
+WHERE email_verified_at IS NULL
+  AND (created_at IS NULL OR created_at <= (
+    SELECT created_at FROM _fluent_migrations
+    WHERE name = 'FlamenetRelay.AddEmailVerification'));
+```
+
+It marks only the accounts that existed before verification arrived. Anyone
+who signed up since still has to confirm their address. Running it a second
+time, or on a relay that never needed it, changes nothing.
+
 ## Telling your users about updates
 
 The Android app asks *your* relay whether a newer build exists, not an address