Bundle the chatto-plugin-update skill with the plugin

The update workflow (fetch before claiming sync status, pull, summarise
new commits for the user, offer the gateway restart via /restart, then
verify) lived only as a locally installed Hermes skill, so any fresh
session without that install had to rediscover every pitfall the hard
way: fetch-first, the lifecycle guard blocking restarts from inside the
gateway, /restart as the right door, and the guard's /dev/null scan
quirk.

Shipped under skills/chatto-plugin-update/SKILL.md so
_register_bundled_skills picks it up on the next gateway start; the
frontmatter description states its trigger because register_skill never
reads the frontmatter itself.

Deployment facts (server, room IDs, cron targets) stay OUT of the repo:
they are installation-specific, so that skill remains a local install.

skills/chatto-plugin-update/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: chatto-plugin-update
+description: "Use when the local Chatto plugin repo must catch up to its remote and the changes must go live in the running Hermes gateway."
+version: 1.0.0
+author: Hermes Agent
+license: MIT
+metadata:
+  hermes:
+    tags: [chatto, plugin, update, git, gateway]
+---
+
+# Chatto-Plugin updaten und Changes aktivieren
+
+## When to Use
+
+Das lokale Chatto-Plugin-Repo auf den Remote-Stand bringen (git fetch/pull) und die neuen Commits im laufenden Hermes Gateway aktivieren (Neustart). Repo: `~/.hermes/plugins/chatto-platform/`, Remote `ssh://gogs.netdome.biz:10022/paul/hermes-chatto-plugin.git`.
+
+## Ablauf
+
+1. **Remote-Status PRÜFEN, nie behaupten:**
+   ```bash
+   git -C ~/.hermes/plugins/chatto-platform fetch --all
+   git -C ~/.hermes/plugins/chatto-platform status -sb
+   git -C ~/.hermes/plugins/chatto-platform branch -avv
+   ```
+   Erst fetchen, dann Sync-Status (ahead/behind) reporten. Aussagen wie "synchron" nur NACH einem `fetch` — der lokale `status -sb` ohne fetch zeigt ahead/behind nur gegen den zuletzt bekannten Remote-Stand. Aktueller Branch: `git branch --show-current`.
+2. **Pull ausführen:** `git pull` (Fast-forward). Bei Divergenz: mit dem User abklären, NICHT automatisch mergen/rebasen.
+3. **Commits zusammenfassen (Nutzersicht):**
+   ```bash
+   git log <alter_stand>..<neuer_stand>          # oneline
+   git log <alter_stand>..<neuer_stand> --stat   # Datei-Umfang
+   ```
+   Commits haben ausführliche Messages — daraus eine nutzerverständliche Zusammenfassung machen: WAS ändert sich für den Bot-Nutzer, nicht Implementierungsdetails. Für jede Änderung eine Quelle angeben (Commit-Hash).
+4. **Gateway-Neustart ANBIETEN (nie selbst ausführen):** Plugin-Code-Änderungen werden erst nach einem Neustart des Hermes-Gateways aktiv — die laufende Session hält das alte Modul im Speicher.
+   - **Einfachster Weg: `/restart` als Chat-Nachricht** (Gateway-Slash-Command, "Restart gateway after draining active runs"). User tippt es direkt im Channel/DM. IMMER zuerst diesen Weg nennen.
+   - Alternative (separate Shell auf dem Host): `hermes gateway restart` oder `systemctl restart hermes-gateway.service`.
+   - **Aus der laufenden Agent-Session heraus ist ein Restart UNMÖGLICH:** der Lifecycle-Guard blockiert jeden Versuch (direkt, via Skript, `at`, `systemd-run`, Aliase/Wrapper), weil der Restart die eigene Session killt. Nicht umgehen versuchen; keine Restart-Skripte/Aliase bauen, wenn `/restart` genügt.
+   - User fragen, ob jetzt neu gestartet werden soll (der laufende Bot ist dann kurz offline).
+5. **Nach dem Neustart verifizieren:** Plugin-Tools live testen (`chatto_list_rooms` via tool_call), im Log prüfen, dass der Adapter sauber lädt.
+
+## Fallstricke
+
+- Aussagen über Sync-Status ("synchron", "aktuell") NUR NACH `git fetch` treffen — ohne fetch ist der lokale Status wertlos.
+- Vendored Updates (chattolib) kommen als dist-info-Rename + RECORD-Änderungen im Pull — normal, kein Handlungsbedarf.
+- Der Lifecycle-Guard blockiert auch Kommandos, die eine Restart-Skript-Datei nur REFERENZIEREN (chmod, bash -n, mv auf den Pfad). Syntax prüfen, indem das Skript vorher unter anderem Namen ins Scratch-Verzeichnis kopiert und dort geprüft wird.
+- Lifecycle-Guard scheitert auch am Scannen von `/dev/null`-Referenzen (z.B. beim Sourcen der `~/.bashrc` im Terminal) — Änderungen an Shell-Dateien stattdessen über Datei-Tools (search_files/patch) verifizieren.