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.

README.md

@@ -111,7 +111,7 @@ TTY detection, and security headers are always applied.
 | `RETENTION_SWEEP_INTERVAL` | How often the retention reaper and archive sweeper run (Go duration, must be positive) | `1h` |
 | `SESSION_IDLE_TIMEOUT`  | Idle session timeout (Go duration)  | `24h`    |
 | `RECEIVER_RATE_LIMIT`   | Receiver requests/minute per IP per entrypoint (10x that per IP across the route) | `120` |
-| `TRUSTED_PROXIES`       | CIDRs whose forwarded headers are trusted (unset: all clients behind a proxy share one rate-limit bucket) | `""` (none) |
+| `TRUSTED_PROXIES`       | CIDRs whose forwarded headers are trusted (unset: all clients behind a proxy share one rate-limit bucket; a correct login password is never throttled either way) | `""` (none) |
 
 #### Trusted proxies
 
@@ -134,13 +134,15 @@ That default is safe against forged headers, but leaving it unset in
 production has a cost you must know about. Production runs behind a
 TLS-terminating reverse proxy, so with `TRUSTED_PROXIES` unset every
 request keys on the proxy's own address and all clients share a single
-bucket per limit. For the login and password-change limits that is a
-denial of service anyone can perform: a steady five POSTs per minute
-from any address on the internet keeps the shared login bucket full,
-and the operator's own login then returns HTTP 429 for as long as the
-trickle continues. There is no second administrative path and no
-bypass. Restarting the service clears the in-memory buckets, but a
-sustained trickle re-locks them immediately.
+bucket per limit. The receiver limits become service-wide ceilings,
+and the login endpoint's failure counting collapses onto one key, so a
+stranger's wrong passwords throttle every other client's wrong
+passwords.
+
+What it cannot do is lock the operator out. The login endpoint
+verifies credentials **before** it consults any limit and charges only
+failures, so a correct password is never throttled no matter how full
+the bucket is. See [Rate Limiting](#rate-limiting).
 
 The remedy is to set `TRUSTED_PROXIES` to your reverse proxy's
 address, which restores per-client buckets. webhooker logs a warning
@@ -378,11 +380,12 @@ It uses:
 - **[gorilla/csrf](https://github.com/gorilla/csrf)** for CSRF
   protection (cookie-based double-submit tokens)
 - **[go-chi/httprate](https://github.com/go-chi/httprate)** for
-  sliding-window rate limiting of the login, password-change and
-  webhook receiver endpoints. The bucket is per client IP only when
+  sliding-window rate limiting of the password-change and webhook
+  receiver endpoints. The bucket is per client IP only when
   `TRUSTED_PROXIES` names the reverse proxy; unset, every client
-  behind that proxy shares one bucket per limit (see
-  [Rate Limiting](#rate-limiting))
+  behind that proxy shares one bucket per limit. The login endpoint
+  counts failed attempts itself instead, so that a correct password is
+  never throttled (see [Rate Limiting](#rate-limiting))
 - **[Prometheus](https://prometheus.io)** for metrics, served at
   `/metrics` behind basic auth
 - **[Sentry](https://sentry.io)** for optional error reporting
@@ -1025,14 +1028,56 @@ opposite directions:
   and all entrypoints, where the per-entrypoint limit's capacity still
   grows with the number of entrypoints. Any deployment with more than a
   handful of busy entrypoints must set `TRUSTED_PROXIES`.
-- For the **login and password-change** limits it costs availability of
-  the only administrative path, which is not safe at all. Five POSTs
-  per minute from any address on the internet keeps the single shared
-  login bucket full, and the operator's own login returns HTTP 429 for
-  as long as that trickle continues. A restart clears the in-memory
-  buckets and a resumed trickle re-locks them. Production deployments
-  must set `TRUSTED_PROXIES`; webhooker warns at startup whenever it is
-  empty, in any environment.
+- For the **login and password-change** limits it costs precision, not
+  availability. Login failures from every client land in one counter,
+  so a stranger's wrong passwords make the operator's own wrong
+  passwords answer `429` sooner; the operator's _correct_ password is
+  never affected, because it is never counted. Production deployments
+  should still set `TRUSTED_PROXIES`; webhooker warns at startup
+  whenever it is empty, in any environment.
+
+#### The login endpoint
+
+The login `POST` is the one endpoint with no pre-emptive limiter in
+front of it, and that is deliberate. A limiter that spends budget on
+arrival is a lockout in this deployment shape: sharing one bucket, a
+stranger sending five POSTs a minute — about 0.08 requests per second,
+from anywhere — keeps it permanently full, and the operator has no
+second administrative path. So the handler inverts the order:
+
+1. **Credentials are verified first, and only a failed attempt spends
+   budget.** A correct password is never rate-limited, whatever the
+   counters hold. This is what guarantees the admin UI stays
+   reachable.
+2. **Failures are counted per (client bucket, submitted username)**,
+   five per minute, after which further _failures_ from that pair are
+   answered `429` with a `Retry-After`. A successful login clears the
+   counter, so mistyping a few times and then getting it right leaves
+   you unthrottled. Because the submitted username is
+   attacker-controlled, at most 1024 username counters and 1024
+   fallback address counters are tracked; past the first cap failures
+   fall back to the address counter, and past both they are answered
+   as throttled without being recorded. Total tracked state is under
+   half a megabyte and does not grow with the number of usernames an
+   attacker invents.
+3. **Concurrent password verifications are capped at two.** Verifying
+   before counting means every login request costs an Argon2id hash,
+   and Argon2id here is 64 MB per hash — two slots is a 128 MB ceiling
+   on password hashing. Every endpoint that hashes a password takes a
+   slot, including the password-change endpoint, which holds one
+   across both the verification and the new hash. A request that waits
+   five seconds without getting a slot is answered `503 Service
+   Unavailable` and no hash is computed for it.
+
+An unknown username is verified against a dummy hash rather than
+rejected early, so a nonexistent account costs the same time as a real
+one and the response cannot be used to enumerate usernames.
+
+The residual exposure is bounded and self-clearing: a flood can keep
+both verification slots busy, so logins queue and some are shed with
+`503` until it stops. That is degraded latency for everyone rather
+than a permanent lockout of the operator, and an operator under one
+can block the source at the reverse proxy or restart the service.
 
 Finer-grained per-webhook rate limits (configured in the web UI and
 enforced in the webhook handler) can layer on top of this env-level
@@ -1053,8 +1098,8 @@ abuse limit later; they are tracked as future work.
 
 | Method | Path            | Description |
 | ------ | --------------- | ----------- |
-| `GET`  | `/pages/login`  | Login page (not rate limited; the limiter applies to POST only) |
-| `POST` | `/pages/login`  | Login form submission (5 per minute per bucket, then 429) |
+| `GET`  | `/pages/login`  | Login page (not rate limited) |
+| `POST` | `/pages/login`  | Login form submission. Credentials are verified before any limit is consulted, so a correct password is never throttled; 5 FAILED attempts per minute per bucket per submitted username, then `429`. `503` if no verification slot frees up within 5s (see [Rate Limiting](#rate-limiting)) |
 | `POST` | `/pages/logout` | Logout (destroys session) |
 
 #### Authenticated Endpoints
@@ -1062,7 +1107,7 @@ abuse limit later; they are tracked as future work.
 | Method | Path                     | Description |
 | ------ | ------------------------ | ----------- |
 | `GET`  | `/user/{username}`       | User profile page |
-| `POST` | `/user/{username}/password` | Change the user's password (5 per minute per bucket, then 429) |
+| `POST` | `/user/{username}/password` | Change the user's password (5 per minute per bucket, then `429`; `503` if no verification slot frees up within 5s) |
 | `GET`  | `/sources`               | List user's webhooks |
 | `GET`  | `/sources/new`           | Create webhook form |
 | `POST` | `/sources/new`           | Create webhook submission |
@@ -1164,6 +1209,7 @@ webhooker/
 │   │   ├── middleware.go      # Logging, CORS, Auth, Metrics, MetricsAuth, SecurityHeaders, MaxBodySize
 │   │   ├── csrf.go            # CSRF protection middleware (gorilla/csrf)
 │   │   ├── ratelimit.go       # Per-IP rate limiting middleware (go-chi/httprate)
+│   │   ├── loginguard.go      # Login failure counters and the Argon2id verification semaphore
 │   │   └── testing.go         # NewForTest: Middleware without the fx lifecycle
 │   ├── server/
 │   │   ├── server.go          # Server struct, fx lifecycle, signal handling