Add member accounts: invites, registration, login, sessions, ban

Step 2 of the build order. The admin mints an invite link, the recipient
registers with it, and from then on has a session.

- The invite is spent in the same transaction that creates the account, so a
  failed signup leaves the code usable
- Sessions are idle timeouts, 24h or 30 days with remember me, read from a
  cookie or a bearer header, extended at most once a minute
- Ban is a reversible toggle that drops the member's live sessions
- No password minimum; login is rate limited instead, 10 failures per email
  in 15 minutes, cleared by a correct password
- Invite codes render as links carrying ?code=, which the register form
  prefills; PUBLIC_URL makes them pasteable from the loopback admin panel

Tests cover invite spending, the idle timeout, ban, and the rate limiter.

docs/decisions.md

@@ -158,3 +158,12 @@ says so.
 40. **`main` is release code, `dev` is development.** Work lands on `dev` and reaches `main` by merge
     at release, so `main` is always a list of things that shipped. Nightly builds, if any, come off
     `dev`.
+41. **No password minimum; rate limit logins instead.** A length policy protects against guessing,
+    and guessing is better answered directly: 10 failures per email in 15 minutes, then a 15-minute
+    lockout, cleared by a correct password. The floor was rejected because typing an 8-character
+    password on every dev account is friction with nothing behind it — there is no public
+    registration to spray, and the admin is the reset path. It was also deliberately *not* made
+    configurable: settings like this belong in code, not in an env file that grows a line per
+    preference. The limiter is keyed by email rather than IP (a proxy would mean trusting
+    `X-Forwarded-For`) and locks the *attempt rate*, not the account, so nobody can lock someone
+    else out by trying.

docs/spec.md

@@ -49,7 +49,12 @@ and a cross-origin page cannot set `Authorization` without CORS, which is not en
 ### 1.2 Security behaviours
 
 - Changing your own password requires the current password.
-- Passwords are bcrypt.
+- Passwords are bcrypt. **There is no minimum length** — only non-empty. Invite-only registration,
+  ten members, and an admin-only reset path leave a length policy nothing to protect.
+- **Login attempts are rate limited**: 10 failures for one email address within 15 minutes lock
+  *that address's login* for 15 minutes, and a correct password clears the counter. Keyed by email
+  rather than IP, because behind a proxy the address requires trusting `X-Forwarded-For`. Held in
+  memory, so a restart clears it. Registration is not limited — an invite code is 128 bits.
 - Invite codes carry 128 bits of entropy (`crypto/rand`, 16 bytes hex).
 - Avatar upload: 5 MB max, normalised through ffmpeg to a 256 px JPEG. The re-encode **is** the
   validation, and it caps what lands on disk. ffmpeg handles webp and avif; stdlib `image` does not.