feat(journal): federation instance blocklist

Task group 3 of federation-hardening. There was no blocklist of any kind;
the only lever against a hostile instance was an IP/host block in Caddy.

- New `federation_blocked_instances` table (domain PK, reason,
  created_at). Additive → created by drizzle-kit push.
- `federation-blocklist.server.ts`: exact-host matching —
  `isBlockedDomain`, `isBlockedIri` (unparseable IRI ⇒ treated as
  blocked), and `filterBlockedDomains` for batch recipient filtering.
- Enforced at all three boundaries (spec: federation-operations
  "Instance blocklist"):
  - inbox — each of the 4 listeners silently drops a blocked actor's
    activity (202, no error oracle) before dedup/side effects;
  - delivery enqueue — `enqueueActivityDeliveries` filters blocked
    recipients in one batch query;
  - outbox poll / actor fetch — `pollRemoteActor` refuses a blocked host
    up front (`skipped: "blocked instance"`), before any network.
- Operator procedure (SQL insert/list/delete) documented in the
  deployment runbook's federation section.
- Tests: unit (hostOfIri) + integration against real Postgres covering
  the helper and the delivery + outbox boundaries; inbox uses the same
  tested isBlockedIri primitive.

Note: the inbox-drop *counter* (federation_inbox_dropped_total{reason})
lands with the other metrics in task 4.2; this commit is the enforcement.

Verified: db + journal typecheck + lint clean; drizzle-kit push creates
the table; blocklist integration tests green against real Postgres;
journal unit suite 357 passing.

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

docs/deployment.md

@@ -140,9 +140,35 @@ document; deliveries signed with the old key fail until then).
   (`federationSourceHost`); 429s show in journal logs.
 - Outbound is paced (1 req/s delivery, 1 req/5 s polling per host).
 - Watch `docker logs <journal>` for `fedify·federation` lines; Loki
-  picks them up. No per-instance blocklist yet — see
-  `docs/ideas/instance-administration.md` (manual emergency lever:
-  block the source IP/host in Caddy).
+  picks them up.
+
+### Blocking an instance
+
+Blocking a domain makes it inert in **both** directions: its inbound
+activities are silently dropped (a 202, no error oracle), we send it no
+deliveries, and we never fetch its actors/outboxes. Matching is
+exact-host. v1 management is a SQL insert/delete against
+`journal.federation_blocked_instances` (the table is the seam a future
+admin UI can sit on); protocol/moderation semantics are in
+[`FEDERATION.md`](../FEDERATION.md).
+
+```sql
+-- Block a hostile instance (exact host, no scheme, no path):
+INSERT INTO journal.federation_blocked_instances (domain, reason)
+VALUES ('bad.example', 'spam / harassment')
+ON CONFLICT (domain) DO NOTHING;
+
+-- List current blocks:
+SELECT domain, reason, created_at FROM journal.federation_blocked_instances ORDER BY created_at DESC;
+
+-- Unblock:
+DELETE FROM journal.federation_blocked_instances WHERE domain = 'bad.example';
+```
+
+The block takes effect immediately (checked per-request/per-job, no
+cache). Already-queued deliveries to the domain drain from Fedify's
+queue; new fan-outs filter it out. An IP/host block in Caddy remains the
+harder emergency lever for a flood that shouldn't reach the app at all.
 
 ### Troubleshooting deliveries