Freigaben einbinden, apt-Installation und RPC-Neustart korrigiert

Drei Fehler, alle drei gemessen statt vermutet.

1. Freigaben wurden nie eingebunden ("mount error(1): Operation not
   permitted"). Ursache war NICHT der Mount-Namensraum, sondern
   SystemCallFilter=@system-service: darin fehlen mount/umount2, und
   SystemCallErrorNumber=EPERM macht daraus genau diese Meldung. Nachgewiesen
   in einem nachgebauten Sandkasten: mit "@mount" gelingt die Einbindung,
   ohne nicht. Die Unit von TESM erlaubt jetzt "@system-service @mount"; alles
   andere an der Haertung bleibt. Der zuvor eingebaute Umweg ueber nsenter ist
   zurueckgenommen -- RestrictNamespaces=yes verbietet setns, er konnte nie
   funktionieren.

   Eingebunden wird damit im Namensraum des Webprozesses. Deshalb ist die
   Aufraeumaufgabe fuer abgelaufene Einbindungen aus dem Ueberwachungsdienst in
   den Webprozess gewandert: ein anderer Dienst sieht diese Einbindungen nicht
   und haette Datenbankzeilen als geloest markiert, waehrend die Freigabe
   eingebunden blieb.

2. apt-Installationen aus der Oberflaeche scheiterten mit "dpkg returned an
   error code (1)". Der Sandkasten wird an dpkg und dessen Maintainer-Skripte
   weitervererbt; mit ProtectKernelLogs=yes liefert "dmesg" ein EPERM und ein
   Postinst-Skript bricht daran ab. apt laeuft jetzt ueber systemd-run, also
   von PID 1 gestartet und damit ohne unsere Haertung.

3. Der RPC-Neustart loeste SSH aus. run_reboot entschied den Weg anhand von
   device["category"] -- und dieser Schluessel bedeutet je Herkunft etwas
   anderes: die Wartungsabfrage legt die Kategorie der *Zugangsdaten* darunter,
   inventory.get_device die des *Geraets*. Ueber die Statusuebersicht kam ein
   Windows-Geraet mit leerer Geraetekategorie an, wurde fuer Linux gehalten und
   ueber SSH auf Port 22 angesprochen, bis das Zeitlimit griff. Der Weg wird
   jetzt uebergeben -- entschieden wird er ohnehin schon vorher in
   restart.resolve. Ausserdem zeigte die Neustart-Historie alles ausser "ssh"
   als "PoE-Port"; RPC hat jetzt einen eigenen Eintrag.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

deploy/systemd/tesm.service

@@ -59,7 +59,20 @@ RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK
 LockPersonality=yes
 MemoryDenyWriteExecute=no
 SystemCallArchitectures=native
-SystemCallFilter=@system-service
+# "@mount" zusaetzlich zu @system-service: die Dateifreigaben werden ueber
+# mount.cifs eingebunden, und @system-service enthaelt mount/umount2 nicht.
+# Ohne diese Ergaenzung scheitert jede Einbindung mit "mount error(1):
+# Operation not permitted" -- gemessen, und zwar unabhaengig von Rechten,
+# Zugangsdaten und Mount-Optionen: aus einer normalen Root-Shell gelingt
+# derselbe Aufruf sofort. Der Umweg ueber nsenter in den Namensraum des Wirts
+# ist keine Alternative, weil "RestrictNamespaces=yes" setns verbietet.
+#
+# Eingebunden wird damit im Mount-Namensraum *dieses* Dienstes. Das ist genau
+# richtig: nur er liest die Dateien, andere Prozesse haben dort nichts zu
+# suchen, und mit dem Dienst verschwinden die Einbindungen wieder. Die
+# Aufraeumaufgabe fuer abgelaufene Einbindungen laeuft deshalb im Webprozess --
+# der Ueberwachungsdienst koennte sie nicht einmal sehen.
+SystemCallFilter=@system-service @mount
 SystemCallErrorNumber=EPERM
 # Bewusst **kein** einschraenkendes CapabilityBoundingSet: sudo braucht
 # CAP_SETUID/CAP_SETGID, und der Helfer dahinter braucht Root. Was hier fehlt,