Registration closes itself once the instance has an owner

Operator: *"registration should be open only for the first user and they get
granted admin privileges. then registration is closed."*

The old shape had a window in it. The first account was always allowed and became
admin; every account after that was gated by `allow_registration` — which
defaulted to ON. So the door stayed open between "my account exists" and "I
remembered to turn it off in Settings", and on a public host that gap is the
entire exposure: it starts the moment DNS resolves and lasts until someone
remembers.

Now the door shuts as a CONSEQUENCE of the admin account existing, in the same
transaction that creates it. Not "defaults closed" — that would still need the
first person to get in somehow. There is no window to remember, because there is
no window.

Re-opening it is a deliberate act in Settings → Access: turn it on, have the
person register, turn it off. Crude, and it is the only mechanism there is —
**there is no invite system**, not even a stub. That is real work (a token table,
admin create/revoke, a redemption flow, expiry) and is filed as later work rather
than smuggled into a release.

An integration test covers it, because it is the interaction between two writes
in one transaction: first register → 201 and `is_admin: true`; the setting is
then false; a second register → 403; re-open deliberately and a third → 201, not
admin.

**This does not retroactively close an instance that already has users.** The
close fires on first-account creation, so a server whose admin predates this
keeps whatever the setting was — which was on. `docs/public-hosting.md` now says
so explicitly, and step 1 of the checklist is "check" rather than "do" for
exactly that reason.

docs/public-hosting.md

@@ -9,14 +9,19 @@ you.
 
 ## Do these four things first
 
-**1. Close registration.** `allow_registration` defaults to **on**, because the first
-run of a fresh instance has to be able to create the admin account. It stays on
-afterwards. Once your own account exists, turn it off in **Settings → Access → Allow
-new registrations**, or the first stranger to find the hostname can open an account on
-your server.
+**1. Check registration is closed.** On a fresh instance this now takes care of
+itself: the first account created becomes the admin *and* closes registration behind
+it, so there is no window between "my account exists" and "I remembered to turn it
+off". A brand-new instance is never locked out of itself, and never left open either.
 
-The first account created is always the admin, regardless of this setting — so a
-brand-new instance is never locked out of itself.
+**Instances that predate this still need one manual flip.** The close fires when the
+first account is created, so a server whose admin already existed keeps whatever
+`allow_registration` was set to — which was **on** by default. Check **Settings →
+Access → Allow new registrations** before exposing an instance you have been running
+on a LAN.
+
+To let someone else in, turn it back on, have them register, turn it off. There is no
+invite system yet, so that is the mechanism.
 
 **2. Terminate TLS in front of it, and forward the scheme.** The app marks the
 session cookie `Secure` and sends HSTS only when it can tell the request arrived over
@@ -88,6 +93,9 @@ Know these before you decide who gets an account.
 - **No per-user storage quota.** Any account can upload attachments until the volume
   is full. `max_attachment_mb` caps a single file, not a total.
 - **No audit log.** Device tokens record `last_used_at`; sign-ins are not recorded.
+- **No invites.** Adding a second person means re-opening registration while they
+  sign up, then closing it again. There is no per-person token, no expiry, and no
+  record of who invited whom.
 
 None of these are hard blockers for an instance whose accounts are you and people you
 know. They are the reason not to hand out open registration to strangers.