Rate-limit the public webhook receiver endpoint (closes #64)

The public receiver /webhook/{uuid} had no rate limiting: anyone
who learns an entrypoint UUID can flood it, inflating the
per-webhook database and the delivery queue.

Add a dedicated limit scoped to the receiver route, keyed per
client IP per request path (the path contains the entrypoint
UUID), so one misbehaving sender is throttled without affecting
other senders of the same entrypoint or other entrypoints.
Requests over the limit get a 429; httprate adds the Retry-After
header per RFC 6585. IP extraction honours X-Forwarded-For,
X-Real-IP, and True-Client-IP for reverse-proxy deployments.

The limit is RECEIVER_RATE_LIMIT requests per minute, default
120, parsed with the existing envPositiveInt strict parser: a
set-but-unparseable or non-positive value aborts startup rather
than silently falling back to the default.

Also update the README env table and Rate Limiting design
section.

README.md

@@ -94,6 +94,7 @@ TTY detection, and security headers are always applied.
 | `METRICS_PASSWORD`      | Basic auth password for `/metrics`  | `""`     |
 | `SENTRY_DSN`            | Sentry error reporting DSN          | `""`     |
 | `SESSION_IDLE_TIMEOUT`  | Idle session timeout (Go duration)  | `24h`    |
+| `RECEIVER_RATE_LIMIT`   | Receiver requests/minute per IP per entrypoint | `120` |
 
 Sessions are bounded by two independent clocks, and end at whichever
 one runs out first:
@@ -123,7 +124,8 @@ fatal configuration error: webhooker logs the offending variable and
 its value and refuses to start, rather than silently running with a
 substituted default. `PORT=eighty`, `DEBUG=ture`, and
 `RETENTION_SWEEP_INTERVAL=1 hour` all abort startup. `PORT` must
-additionally be a number in the range 1–65535.
+additionally be a number in the range 1–65535, and
+`RECEIVER_RATE_LIMIT` must be at least 1.
 
 Boolean variables (`DEBUG`, `MAINTENANCE_MODE`) accept exactly the
 spellings Go's `strconv.ParseBool` accepts — `1`, `t`, `T`, `TRUE`,
@@ -785,17 +787,24 @@ just delayed until the target is healthy again.
 
 ### Rate Limiting
 
-Global rate limiting middleware (e.g., per-IP throttling applied at the
-router level) **must not** apply to webhook receiver endpoints. Webhook
-endpoints receive automated traffic from external services at
-unpredictable rates, and blanket rate limits would cause legitimate
-deliveries to be dropped.
+Global blanket rate limiting middleware (e.g., a per-IP throttle shared
+with the web UI) **must not** apply to webhook receiver endpoints.
+Webhook endpoints receive automated traffic from external services at
+unpredictable rates, and blanket limits shared with other routes would
+cause legitimate deliveries to be dropped.
 
-Instead, each webhook has its own individually configurable rate limit,
-applied within the webhook handler itself. By default, no rate limit is
-applied — webhook endpoints accept traffic as fast as it arrives. Rate
-limits can be configured per-webhook when needed (e.g., to protect
-against a misbehaving sender).
+The receiver instead has its own dedicated abuse limit, scoped to the
+`/webhook/{uuid}` route only and keyed per client IP per entrypoint: one
+misbehaving sender is throttled without affecting other senders of the
+same entrypoint or the same sender's other entrypoints. The limit is
+`RECEIVER_RATE_LIMIT` requests per minute (default 120, generous for
+legitimate webhook senders). Requests over the limit receive HTTP 429
+with a `Retry-After` header. A set-but-invalid `RECEIVER_RATE_LIMIT`
+value aborts startup rather than silently falling back to the default.
+
+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
+abuse limit later; they are tracked as future work.
 
 ### API Endpoints