memory: althing deploy is one command now, and eshpfi owns the plugin hop

Recorded the ownership call, which forseti left open. The plugin deployer
lives in eshpfi rather than the althing repo because it targets
per-machine paths, and althing's sync_skill.sh deliberately reaches into
no other tree. Putting a plugin installer upstream would break that
boundary for one consumer's convenience. Their repo stays the source;
this one does the installing.

persistent-memory.md

@@ -194,6 +194,12 @@ _As of 2026-09-01 — **the GX10 is on the operator's desk, NOT racked. Standing
   latency + status-not-durable in the skill. 🔵 **PENDING OPERATOR:** the kimi/pi seats guard 4
   cannot cover — poke unguarded / write-without-Enter / pull-only. **Recommended per-seat
   status quo**; write-without-Enter beats it for neither seat.
+  ✅ **DEPLOY IS NOW ONE COMMAND: `scripts/deploy-althing.sh`** (`--check` reports drift),
+  documented in `docs/runbooks/althing-deploy.md`. **FOUR surfaces**: tool install (⚠ `--force`
+  or it is a silent no-op), herald restart, skill sync, **plugin reinstall** — the fourth had no
+  runbook step and drifted 5 days, costing the SessionStart auto-declare hook entirely.
+  ⚠ **eshpfi owns the plugin deploy, NOT the althing repo** — it targets per-machine paths, and
+  althing's `sync_skill.sh` deliberately reaches into no other tree; that boundary is correct.
   → `persistent-memory.d/2026-09-01-althing-320-deploy.md`
 - **✅ A6000 window CLOSED 2026-09-01 — operator freed ComfyUI's VRAM instead of anyone
   stopping it.** ⚠ It was a **model unload, not a stop**: `comfyui` still up 8 days, same pid,