docs: retention direction for the coordination log, and drop the operator's name from RFC 002 §5

RFC 003 §9.1 — retention is settled in direction (rotate old traffic out of
the way, logrotate-style, moved aside rather than destroyed) and the sketch
records the parts that are not obvious:

- Tier artifacts before events. Events are a few KB; artifacts are capped at
  4 MiB and stored in-row, so moving artifact CONTENT cold while keeping the
  kind/sha256/size/created_by stub reclaims nearly all the space and keeps the
  audit trail ("what was handed over, by whom, verified how") intact.
- If events rotate at all, the unit is the correlation_id THREAD whose latest
  event is terminal — never the row. Archiving an ask while leaving its reply
  (or the reverse) breaks the owed-set join, and both failure modes are bad:
  an ask that can never be cleared resurfaces as owed forever, or a reply is
  orphaned from what it answered.
- Never rotate an event that is still owed. Owed-ness is DERIVED at read time,
  so an unanswered ask is indistinguishable from a stale one except by that
  derivation — a purely time-based sweep would discard the live obligations of
  a machine that has merely been offline for a month, which is precisely the
  case this log exists to serve.
- Rotation invalidates held cursors: since_event_id RAISES on an unknown id
  (§7.5), so archiving an event a watcher holds as its resume point turns its
  next poll into an error. Either announce rotation ahead of live cursors, or
  teach the anchor lookup to fall back to created_at/hlc.
- Archive → verify (row counts, artifact sha256) → only then DELETE + VACUUM,
  with a --dry-run that reports in thread units.

RFC 002 §5: "Open decisions for ALC" → "Open decisions". RFC 001 never names
the operator anywhere; impersonal is the mature precedent and ALC was never a
real identifier in the first place (it is the AAAK spec's illustrative code for
"Alice", copy-forwarded into ~700 diary entries without verification).

Same edit also removes two device names and a hostname from §5.3, which is
host inventory and belongs in the private fleet repo, not a public one. The
mechanism it teaches — a palace in a Docker named volume dies on the next
container recreate, so census before flipping — is unchanged and is the part
that mattered.

docs/rfc-002-joiner.md

@@ -183,12 +183,12 @@ correctness, not for this join.
 `filed_at` spread over the same parent drawers — 12 in May, 52 in June, 13,619 in July, 882 in August — is
 the concrete case for regime A: an MCP replay would restamp all of it to the join date.
 
-## 5. Open decisions for ALC
+## 5. Open decisions
 
 1. **Chronology: keep it or flatten it?** Regime A keeps it and costs a service stop plus an rsync of the
-   source palace onto synlig. Regime B is simpler and loses it. This is the fork in the road.
+   source palace onto the primary host. Regime B is simpler and loses it. This is the fork in the road.
 2. **Hallways for joined content:** re-mine to rebuild, or accept degraded `traverse`?
-3. **Do MBP-M1-2020 and tor-ms22 keep their palaces on persistent storage?** If either is a Docker named
+3. **Do the secondary machines keep their palaces on persistent storage?** If a palace lives in a Docker named
    volume rather than a bind mount, its un-migrated content dies on the next container recreate — so the
    census (Phase A) is time-sensitive there, and flipping before censusing is risky.
 4. **Does §7.6 get fixed client-side (in the joiner) or upstream (probe-and-skip in `diary_write`)?** The