raf: desktop component + local trust boundary + fleet-join maintainability

- components/05-desktop.md: the tray as credential-less localapi client; no-token surface marked as open decision (peer identity unanswered), not doctrine
- trust-boundaries: Local boundary section — the kernel is the middleware, group stamping at login is the sharp edge
- standalone-authority: fleet join must stay idempotent, single-source gated, and tested in both directions

RAF/security/06-standalone-authority.md

@@ -107,6 +107,23 @@ fallback authority in fleet mode. A fleet host that loses its server does what i
 today: nothing installs until the server returns (constraint #3's verified-cache
 fallback applies only to already-minted operations).
 
+**Transition maintainability (Casey, 2026-06-12).** Fleet join is a supported
+lifecycle path, not a one-off migration script — it must hold to the same standard
+as install/upgrade: idempotent, re-runnable, verified by the post-join healthcheck
+rather than assumed (`docs/tasks/INSTALL-001` is the enforcement pattern). Two
+standing rules keep it from rotting:
+
+1. **Gate logic stays single-source.** Standalone and fleet share the same gate
+   code (vuln full-stop, soak, age, hash verification). When a gate gains a
+   fleet-side capability (e.g. DB-backed policy config), the standalone resolution
+   path must be extended in the same change — a gate that behaves differently per
+   mode is drift, not configuration.
+2. **The join flow is exercised, not trusted.** Keyring replacement, key
+   destruction, and journal upload need test coverage that runs both directions of
+   the matrix (fresh-fleet install vs standalone-then-join must converge on
+   identical end state). If the two end states can diverge, the transition has
+   already broken — it just hasn't been noticed yet.
+
 ## Non-goals
 
 - No local approval authority in fleet mode (server remains sole authority).