FileRW: Sammel-Lesen (#663) und Hinweis auf den anderen Workspace (#662)

#663: Neue Aktion read_many liest mehrere Dateien in einem Aufruf - entweder
paths (Liste) oder path (Verzeichnis) mit pattern. Gedeckelt auf 50 Dateien und
200.000 Zeichen; was nicht mehr hineinpasst, wird namentlich genannt, damit der
Agent gezielt nachholen kann. Anlass: Der Tagesabschluss im Testbetrieb las 24
Stundendateien einzeln und starb zweimal an der Schrittgrenze - die soll
Endlosschleifen abfangen, nicht ehrliche Arbeit.

#662: Schlaegt read oder list fehl, weil der Pfad im anderen Workspace liegt,
sagt die Fehlermeldung das - aber nur, wenn der Agent diesen Workspace auch
benutzen darf. Guenstige Modelle vergassen workspace "shared" regelmaessig und
verbrauchten mit jedem Rateversuch einen Schritt.

Dateipruefung, Endungen und Workspace-Grenze gelten in read_many unveraendert;
eine verbotene Endung wird uebergangen statt den Lauf zu kippen.

Version 0.1.14.

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

docs/ToolDevelopmentGuide.md

@@ -256,7 +256,17 @@ Der `AgentEngine` nutzt dann die `ToolRegistry`, um für jeden Agent nur die erl
 |---|---|
 | Name | `FileRW` |
 | NuGet | (keine) |
-| Aktionen | `read`, `write`, `append`, `list`, `delete` |
+| Aktionen | `read`, `read_many`, `write`, `append`, `list`, `delete`, `copy`, `stock_add` |
+
+`read_many` liest mehrere Dateien in einem Aufruf – entweder `paths` (Liste) oder `path`
+(Verzeichnis) mit `pattern`. Gedeckelt auf 50 Dateien und 200.000 Zeichen; was nicht mehr
+hineinpasst, steht namentlich am Ende der Antwort. Der Grund steht in #663: Ein Lauf, der
+24 Dateien einzeln liest, verbraucht 24 Schritte und stirbt an der Schrittgrenze – die soll
+Endlosschleifen abfangen, nicht ehrliche Arbeit.
+
+Schlägt ein Zugriff fehl, weil der Pfad im *anderen* Workspace liegt, sagt die
+Fehlermeldung das (#662) – aber nur, wenn der Agent den anderen Workspace auch benutzen
+darf.
 
 **Config-Felder:**
 - `rootPath` – Basisverzeichnis (Agent ist darin eingesperrt)