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/multi-day-collections.md

@@ -0,0 +1,45 @@
+# Multi-day activity collections
+
+Pre-spec exploration. This is `docs/architecture.md`'s **explicit open
+question #1** (§Multi-Day Route Support: "Exact data model for
+collections TBD — needs more design work"). Multi-day *routes* shipped
+(day-break waypoints, per-day stats, track segments per day); the
+activity side — recording a 5-day bikepacking trip as one entity with
+five day-recordings — is captured nowhere.
+
+## The shape from the architecture
+
+- A multi-day activity is a **collection linking individual
+  day-activities**
+- Each day-activity keeps its own GPS trace, photos, description
+  (possibly imported from different devices/apps per day)
+- The collection references the planned multi-day route as a whole
+- Day-activities can be imported one at a time (Garmin/Komoot/Wahoo per
+  day) and attached as the trip progresses
+
+## Data-model directions to evaluate
+
+1. **Collection row + membership table** —
+   `journal.trips (id, owner, name, description, route_id?)` +
+   `journal.trip_activities (trip_id, activity_id, day_index)`.
+   Activities stay fully independent (visibility, federation, photos);
+   the trip is a presentation/grouping layer. Cheapest; probably right.
+2. **Self-referencing activities** (`parent_activity_id` + a `kind`
+   column). Fewer tables but overloads the activity model and makes
+   feed/outbox queries carry exclusion rules forever.
+3. Whatever we pick must answer: trip-level visibility vs per-day
+   visibility (suggest: trip visibility caps day visibility), trip-level
+   stats (sum of days), and how a trip federates (one Note per day as
+   today, plus a trip page link? A trip-level Note at completion?).
+
+## Notes
+
+- Pairs naturally with `activity-participants.md` (group trips) and the
+  "Tour mode" sketch in `fediverse-enhancements.md` (day N/M check-in
+  posts are trivial once a trip entity exists).
+- The route side already encodes day breaks in GPX track segments —
+  importing a multi-day route's recording per segment could pre-seed
+  day-activities.
+- Keep GPX exportability: a trip should export as one GPX with track
+  segments per day (mirror of the route format), preserving the
+  data-ownership principle.