Verify login credentials before spending rate-limit budget (closes #150)

With TRUSTED_PROXIES empty behind the reverse proxy production is
required to run behind, every login POST keyed on the proxy's address
and shared one 5/minute bucket. A stranger sending five POSTs a
minute -- 0.08 requests per second, from anywhere -- kept that bucket
permanently full, and the operator's own correct password was answered
429 indefinitely with no second administrative path.

The login POST no longer has a pre-emptive limiter. The handler
verifies credentials first and spends budget only on a FAILED attempt,
so a correct password is never throttled whatever the counters hold.
Three things follow, and are implemented together because the first is
unsafe without the other two:

- Failures are counted per (client bucket, submitted username), five
  per minute, after which further failures get 429 with a Retry-After.
  A successful login clears the counter, so mistyping and then
  succeeding does not leave the operator throttled.
- Both key sets are capped at 1024 entries. The submitted username is
  attacker-controlled, so past the first cap failures fall back to a
  counter keyed on the client alone, and past both caps a failure is
  answered as throttled without being recorded. Tracked state stays
  under half a megabyte and does not grow with invented usernames.
- Concurrent Argon2id verifications are capped at two, a 128 MB
  ceiling at 64 MB per hash. Every password-hashing endpoint takes a
  slot, including the password-change endpoint, which holds one across
  both its hashes. A request that waits five seconds without a slot is
  answered 503 and no hash runs for it.

An unknown username is verified against a dummy hash instead of
returning early, so a nonexistent account costs the same time as a
real one and the response cannot be used to enumerate usernames.

The password-change limiter is unchanged: RequireAuth runs ahead of
it, so only a request already carrying a valid session reaches its
bucket.

Also adds the missing test for the third bucketKey call site, where
the peer is a trusted proxy but the forwarded chain names no client.
Every existing test of that fallback uses an IPv4 proxy, where
bucketKey is the identity function, so dropping the /64 masking there
left the suite green.

README and the TRUSTED_PROXIES startup warning updated: a shared
bucket now costs precision, not the availability of the admin path.

internal/middleware/ratelimit.go

@@ -12,11 +12,15 @@ import (
 )
 
 const (
-	// loginRateLimit is the maximum number of login attempts
-	// per interval.
+	// loginRateLimit is the maximum number of FAILED login attempts
+	// one client may make against one submitted username per
+	// interval before further failures are answered 429. Successful
+	// attempts are never counted and never throttled — see
+	// loginGuard.
 	loginRateLimit = 5
 
-	// loginRateInterval is the time window for the rate limit.
+	// loginRateInterval is the time window for the login failure
+	// limit.
 	loginRateInterval = 1 * time.Minute
 
 	// passwordChangeRateLimit is the maximum number of password
@@ -216,7 +220,7 @@ func (m *Middleware) clientKey(r *http.Request) string {
 	return bucketKey(peer)
 }
 
-// tooManyRequests returns the 429 handler used by the login,
+// tooManyRequests returns the 429 handler used by the
 // password-change and per-entrypoint receiver limiters: it logs the
 // rejection with logMessage and answers with responseMessage.
 // httprate adds the Retry-After header (RFC 6585). The aggregate
@@ -255,26 +259,15 @@ func (m *Middleware) floodTooManyRequests(
 	}
 }
 
-// LoginRateLimit returns middleware that enforces per-IP rate
-// limiting on login attempts using go-chi/httprate. Only POST
-// requests are rate-limited; GET requests (rendering the login
-// form) pass through unaffected. When the rate limit is exceeded,
-// a 429 Too Many Requests response is returned. Clients are
-// identified by rateLimitKey.
-func (m *Middleware) LoginRateLimit() func(http.Handler) http.Handler {
-	return m.postRateLimit(
-		loginRateLimit,
-		loginRateInterval,
-		"login rate limit exceeded",
-		"Too many login attempts. Please try again later.",
-	)
-}
-
 // PasswordChangeRateLimit returns middleware that enforces
 // per-IP rate limiting on password change attempts. The change
 // endpoint verifies the current password, so without a limit a
-// stolen session could be used to brute-force it; the limit
-// matches the login endpoint's.
+// stolen session could be used to brute-force it.
+//
+// Unlike the login POST this limit is still spent on arrival, which
+// is safe here: RequireAuth runs ahead of it, so only a request
+// already carrying a valid session can reach the bucket, and an
+// operator locked out of changing a password can still log in.
 func (m *Middleware) PasswordChangeRateLimit() func(http.Handler) http.Handler {
 	return m.postRateLimit(
 		passwordChangeRateLimit,