fix(recover): cap name cycling, and stop bcrypt blocking the runtime

Round 1 gave /join a per-IP ceiling and left /recover with only its
`recover:{ip}:{name}` bucket. That key is right for the job it was written for —
stopping someone who knows a display name (they're listed on the feed) from
burning the victim's 3-strike PIN counter and locking them out on repeat. But the
name is ATTACKER-CHOSEN, so cycling names mints a fresh 5-attempt bucket every
time and the per-IP cost is unbounded.

What sits behind that limiter makes it worse than a normal flood: every call runs
a cost-12 bcrypt verify, including an UNCONDITIONAL throwaway verify for names
that don't exist — added deliberately to close a timing oracle. So an unknown name
is the single cheapest way to make the server do ~200ms of hashing.

Adds `recover_ip_rate_per_min` (default 30, migration 019), checked BEFORE the
per-name bucket so a name generator can't walk past it. 30/min is far above any
real recovery attempt while capping a flood. The per-name bucket is untouched and
remains the anti-guessing control.

The second half matters as much as the first: bcrypt was running inline on the
async runtime everywhere. At cost 12 that pins a tokio worker thread for ~200ms,
and there is only one per core — so a login flood stalled every other request on
the box, including the feed. There was no spawn_blocking anywhere in the auth
module, despite SECURITY-BACKLOG claiming bcrypt had been offloaded.

Route all of it through `verify_password` / `hash_password` on the blocking pool.
That covers /recover, /admin/login, the host PIN reset, and — the one most likely
to bite at a real event — the PIN hash minted on every single /join. Saturating
the blocking pool degrades logins; saturating the worker threads degrades
everything.

Tests: cycling distinct names from one IP now hits the ceiling with a Retry-After,
and — the assertion that keeps the fix honest — repeated wrong PINs against ONE
name are still throttled with the ceiling set generously high, so the ceiling
added protection rather than replacing it.

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

backend/migrations/019_recover_ip_rate.up.sql

@@ -0,0 +1,19 @@
+-- Per-IP flood ceiling for /recover, mirroring the one migration 017 added for /join.
+--
+-- Rationale: /recover is keyed `recover:{ip}:{name}` at 5 per 15 minutes. That is the
+-- right shape for its actual job — stopping someone who knows a display name (they are
+-- visible on the feed) from burning the victim's 3-strike PIN counter and locking them
+-- out repeatedly. But the name is attacker-chosen, so cycling names mints a fresh bucket
+-- every time and the per-IP cost is unbounded.
+--
+-- Behind that limiter sits a cost-12 bcrypt verify, including an UNCONDITIONAL throwaway
+-- verify for names that don't exist — deliberately, to close a timing oracle. So an
+-- unknown name is the cheapest possible way to make the server do ~200ms of hashing.
+-- Without a ceiling, one client can saturate the box's CPU with a name generator.
+--
+-- 30/min is far above any real recovery attempt (a guest tries their PIN a handful of
+-- times) while capping a name-cycling flood. The per-(ip, name) bucket is unchanged and
+-- remains the anti-guessing control.
+INSERT INTO config (key, value) VALUES
+    ('recover_ip_rate_per_min', '30')
+ON CONFLICT (key) DO NOTHING;