docs: capture remaining architecture vision; draft route-federation change

Gap analysis of docs/architecture.md against openspec/ and docs/ideas/
found the envisioned-but-uncaptured remainder. This commit captures it:

New OpenSpec change (validated):
- route-federation — the collaboration half of the federation vision:
  routes as dereferenceable trails:Route objects, Create/Update
  fan-out, Invite/Accept collaboration mirroring (arch decision #2),
  cross-instance Planner edits via HTTP-Signature-requested scoped
  tokens (decisions #3/#12), mirror sync healing (#16). Depends on
  social-federation §6 + route-sharing; carries the 2026-06-07 soak
  lessons as design constraints.

New docs/ideas/ explorations:
- instance-administration — registration toggle, suspend/ban,
  federation blocklists, reports (moderation now gates the federated
  comments idea)
- social-interactions — local likes + comments (don't exist even
  locally; the foundation federated kudos/comments attach to)
- activity-participants — group tagging with confirm/decline +
  federated mentions (the participants jsonb column is an untyped stub)
- multi-day-collections — architecture open question #1, directions
  evaluated

architecture.md cleanup:
- Mastodon-compat section annotated with shipped/captured state + the
  live-soak interop lessons (attachment arrays, tombstones, 10s
  timeout, no backfill)
- api.trails.cool removed (contradicted resolved decision #18)
- Phase 1 ticked (shipped); Phase 2/3 items annotated with where each
  is tracked; specs/ → openspec/, activity.* → journal.*, cx21 → cx23
- brouter-web open question marked resolved-in-practice; new section
  pointing to where the unshipped vision is tracked

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

docs/ideas/instance-administration.md

@@ -0,0 +1,49 @@
+# Instance administration & moderation
+
+Pre-spec exploration. Envisioned in `docs/architecture.md` (§Instance
+Administration) since day one, never spec'd. Now that federation is live
+on staging — a public inbox accepting traffic from arbitrary instances —
+the moderation half has moved from "eventually" to "before the federated
+surface grows."
+
+## Scope sketch
+
+**Instance settings**
+- Instance name, description, rules page (rendered at `/about`)
+- Open/close registration (env var today at best; should be a runtime
+  admin setting)
+- Instance-level contact / operator info (some of this exists for the
+  legal pages — consolidate)
+
+**User management**
+- Admin role (first user? env-designated? explicit grant)
+- Suspend / unsuspend users (suspended: no login, content hidden,
+  federation stops — actor 404s like a private profile)
+- Delete user + content (GDPR path; account-management spec covers
+  self-deletion, not admin-initiated)
+
+**Federation management**
+- Per-instance blocklist: refuse inbox traffic, drop follows, stop
+  deliveries to blocked domains (checked in the inbox rate-limit layer
+  we already have — `federationSourceHost` is the natural hook)
+- Per-instance silence (content hidden from shared surfaces but
+  follows still work) — maybe later; block first
+- Visibility into federation peers: which instances follow us /
+  we deliver to, volumes, error rates (remote_actors table + Fedify
+  logs already hold most of this)
+
+**Reports & moderation queue**
+- Report content/users (local reports first; ActivityPub `Flag`
+  federation later)
+- Simple queue: open → resolved/dismissed, with action taken
+
+## Constraints & notes
+
+- Mastodon's admin model is the obvious reference; ours can be a tiny
+  subset (single-admin instances are the norm for self-hosters).
+- The federated-comments idea (`fediverse-enhancements.md`) explicitly
+  depends on at least instance blocks + report handling existing.
+- Suspension must compose with federation the same way profile privacy
+  does today: suspended ⇒ actor 404, push delivery suppressed (the
+  `social-federation` spec's 9.3 mechanics generalize).
+- Admin surfaces are user-facing strings → i18n from the start (en+de).