fix(rate-limit): key the guest-facing limiters per user, not per IP

At a venue every guest is behind one NAT, so an IP-keyed limiter hands the
whole party a single bucket. On a fresh deploy 12 guests arriving together
meant 5 joined and 7 were turned away, with no Retry-After telling them when
to retry. `/feed` (60/min) and `/export` (3 per DAY — the fourth guest to
fetch their keepsake locked out until tomorrow) had the same defect.

`feed_delta` was already keyed per-user and its comment states the exact
rationale ("so one client can't starve others behind a shared NAT"); this
makes its siblings match.

- feed:{ip}   -> feed:{user_id}    (auth was already in scope)
- export:{ip} -> export:{user_id}  (resolved from the download ticket's
  session, which was previously looked up and discarded)
- join:{ip}: pre-auth, so there is no user to key on. Split in two — a loose
  per-IP ceiling that only bounds raw volume (new `join_ip_rate_per_min`,
  default 60, migration 017), plus the real 5/60s anti-spam bucket keyed
  per (ip, name), mirroring the existing `recover:{ip}:{name}`.

admin_login / recover / pin_reset_req stay IP-keyed on purpose and are now
commented as such: they guard credential guessing, where a per-user or
per-name key would just hand an attacker a fresh bucket per guess.

Retry-After: the machinery existed but 7 of 8 sites called `check()` and
hard-coded `None`, so a throttled client was told to back off but never for
how long. Delete the bool `check()` wrapper entirely so `check_with_retry`
is the only entry point and the delay cannot be discarded by accident. Also
surface it for the PIN lockout, where the deadline was already known.

Fix the "unknown" fallback while here: every client_ip() caller passed that
literal, so any request without X-Forwarded-For — anything reaching the app
directly rather than through Caddy — shared ONE global bucket. Serve with
connect-info and use the peer address.

Tests: the reseed forces every limiter toggle off before each test, which is
why this whole class was invisible. Add 01-auth/rate-limit-shared-nat, which
enables them and asserts 12 guests share an IP without collision, that one
guest hammering their own name IS still throttled (so the fix re-keys rather
than removes the limit), and that feed/export buckets are per-user. Retarget
the ddos join test at the new per-IP ceiling — it asserted the defect.

Also seed `admin_login_rate_enabled` (read by the handler, seeded by no
migration and no reseed) and register `join_ip_rate_per_min` in the admin
config allowlist. Unrelated pre-existing red test fixed: 01-auth/join
asserted a "Willkommen!" heading the wedding redesign removed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

backend/src/handlers/test_admin.rs

@@ -13,9 +13,10 @@ use crate::auth::middleware::RequireAdmin;
 use crate::error::AppError;
 use crate::state::AppState;
 
-/// Truncates every event-scoped table, wipes media on disk, and reseeds the
-/// `config` table from migration defaults. Requires an admin JWT — even with
-/// `EVENTSNAP_TEST_MODE=1` it cannot be hit anonymously.
+/// Truncates every event-scoped table, wipes media on disk, and reseeds the `config`
+/// table: numeric values from the migration defaults, but every feature toggle forced
+/// OFF (production seeds them ON — see the note at the reseed below). Requires an admin
+/// JWT — even with `EVENTSNAP_TEST_MODE=1` it cannot be hit anonymously.
 pub async fn truncate_all(
     State(state): State<AppState>,
     RequireAdmin(_auth): RequireAdmin,
@@ -40,8 +41,19 @@ pub async fn truncate_all(
     .execute(&state.pool)
     .await?;
 
-    // Reseed config — mirrors migrations 005, 009 and 015. Kept in sync by hand
-    // because pulling SQL out of the migration files at runtime is fragile.
+    // Reseed config. The NUMERIC values mirror migrations 005/015/016; the BOOLEAN
+    // toggles deliberately do NOT — migration 009 seeds every one of them `true`
+    // (production), and this forces them `false` so the suite isn't fighting rate limits
+    // and quotas it isn't testing.
+    //
+    // Be aware of what that costs: this runs as an auto-fixture before EVERY test, so no
+    // test starts from production's config unless it explicitly turns a toggle back on
+    // (02-upload/rate-limit, 07-adversarial/ddos, 01-auth/rate-limit-nat, …). That blind
+    // spot is exactly why an entire class of per-IP limiter bugs went unnoticed: the
+    // limiters were simply off. When adding a limiter or quota, add a spec that enables it.
+    //
+    // Kept in sync by hand because pulling SQL out of the migration files at runtime is
+    // fragile — if you add a config key in a migration, add it here too.
     sqlx::query(
         r#"INSERT INTO config (key, value) VALUES
             ('max_image_size_mb',          '20'),
@@ -49,6 +61,7 @@ pub async fn truncate_all(
             ('upload_rate_per_hour',       '100'),
             ('feed_rate_per_min',          '60'),
             ('export_rate_per_day',        '3'),
+            ('join_ip_rate_per_min',       '60'),
             ('quota_tolerance',            '0.75'),
             ('estimated_guest_count',      '100'),
             ('compression_concurrency',    '2'),
@@ -57,6 +70,7 @@ pub async fn truncate_all(
             ('feed_rate_enabled',          'false'),
             ('export_rate_enabled',        'false'),
             ('join_rate_enabled',          'false'),
+            ('admin_login_rate_enabled',   'false'),
             ('quota_enabled',              'false'),
             ('storage_quota_enabled',      'false'),
             ('upload_count_quota_enabled', 'false'),