Wiederaufnahme nach Absturz, Nachschau und Auswertung (#553-#556)

#553 FileRW schreibt atomar. Die Vorkehrung lag seit #241 im selben
Repository und wurde ueberall benutzt - Einstellungen, Sicherungen,
Chat-Zustand, Identity.md - nur der Weg, ueber den Agenten ihre
Arbeitsergebnisse ablegen, ging daran vorbei. Damit stand das Verhaeltnis
auf dem Kopf: geschuetzt war das Eigene, ungeschuetzt das Ergebnis.
append bleibt bewusst nicht atomar; das ginge nur, indem die ganze Datei
neu geschrieben wird, und bei einer grossen Protokolldatei waere das der
falsche Handel.

#554 Wiederaufnahme. Neuer Eintrag AuditStatus.Started, geschrieben VOR
der Wirkung und als einziger nicht "best effort" - auf ihn stuetzt sich
alles Weitere, also laeuft der Aufruf gar nicht erst, wenn er nicht
durchkommt. Neue Kennzeichnung IsRepeatable, getrennt von IsParallelSafe:
Das eine heisst "stoert keinen gleichzeitigen Aufruf", das andere
"richtet zweimal keinen Schaden an". CrashRecovery sichtet beim Start,
was offen blieb, und stuft ein - fuehrt aber nichts aus. Es sichtet und
berichtet; entscheiden soll der Aufrufer.

Dabei kippte eine alte Regel: Bisher wurde ein Abbruch bewusst NICHT
protokolliert. Das war richtig, solange es keinen Eintrag vor dem Aufruf
gab. Jetzt saehe sonst jeder Benutzerabbruch beim naechsten Start aus wie
ein Absturz - bis niemand mehr hinsieht. Deshalb AuditStatus.Cancelled.

#555 Optionale Zustandspruefung IToolStateProbe, umgesetzt in FileRW.
Unknown ist eine vollwertige Antwort, kein Fehlschlag: Ob ein SMTP-Server
angenommen hat, laesst sich nicht feststellen, und ein Werkzeug, das hier
raet, waere schlimmer als eines, das schweigt. Partial gilt ausdruecklich
nicht als geklaert - einen halb angehaengten Text sollte niemand
automatisch geraderuecken.

#556 Auswertung. ListForAgentAsync und SummarizeToolUsageAsync. Die Dauer
wird nur ueber abgeschlossene Aufrufe gemittelt; zaehlten die
Started-Eintraege mit ihrer Dauer 0 mit, saehe jedes Werkzeug doppelt so
schnell aus, wie es ist.

Nebenbei: SqliteStorage kann jetzt Spalten nachruesten. CREATE TABLE IF
NOT EXISTS allein genuegte nicht - bei einer bestehenden Datenbank tut die
Anweisung nichts, und erst das naechste INSERT waere gescheitert, im
Betrieb beim Anwender.

Vier Audit-Tests angepasst: Ein ausgefuehrter Aufruf erzeugt jetzt zwei
Eintraege statt einem. Ein Aufruf, der gar nicht erst laeuft - verweigert,
unbekannt, vorgelegt - hat weiterhin genau einen; der Beginn wird erst
nach Rechtepruefung und Staging geschrieben.

23 neue Tests, 912 gesamt, keine Regression. Build ohne Warnungen.

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

src/ClawdDotNet.Core/Tools/IAgentTool.cs

@@ -23,6 +23,25 @@ public interface IAgentTool
     /// </summary>
     bool IsParallelSafe => false;
 
+    /// <summary>
+    /// Ob ein zweiter, gleicher Aufruf schadlos bleibt (#554).
+    ///
+    /// <para>Gebraucht wird das nach einem harten Absturz: Im Protokoll steht, dass ein
+    /// Aufruf begann, nicht ob er wirkte. Bei einem wiederholbaren Werkzeug muss man das
+    /// auch nicht wissen — man ruft es einfach noch einmal. Bei allen anderen bleibt nur,
+    /// den Fall vorzulegen statt zu raten.</para>
+    ///
+    /// <para>Nicht zu verwechseln mit <see cref="IsParallelSafe"/>. Das heißt „stört
+    /// keinen gleichzeitigen Aufruf", dies hier heißt „richtet zweimal keinen Schaden an".
+    /// Ein Werkzeug kann das eine sein und das andere nicht: Eine Datei zu überschreiben
+    /// ist wiederholbar — zweimal derselbe Inhalt ergibt denselben Zustand —, verträgt
+    /// aber keinen zweiten Schreiber zur selben Zeit.</para>
+    ///
+    /// <para>Vorgabe <c>false</c>, aus demselben Grund wie oben: Wer sich irrt, versendet
+    /// die Mail zweimal.</para>
+    /// </summary>
+    bool IsRepeatable => false;
+
     Task<ToolResult> ExecuteAsync(
         JsonElement input,
         AgentToolContext context,