chore: remove the completed telegram working dirs

Both dirs are finished-task artifacts now that the merge and the liveness check have landed. Every file is already in git history via b19d420 and bff0138. Deleting the working copies loses nothing, and a copy under assets/ would only duplicate what git holds. Nothing links to either dir.

1 files changed, 0 insertions, 17 deletions

diff --git a/working/triage-telegram-segfault-rootcause/note-0721-correction.org b/working/triage-telegram-segfault-rootcause/note-0721-correction.org
deleted file mode 100644
index 73e9274..0000000
--- a/working/triage-telegram-segfault-rootcause/note-0721-correction.org
+++ /dev/null
@@ -1,17 +0,0 @@
-#+TITLE: CORRECTION to the triage-intake.telegram.org write-up sent a
-#+SOURCE: from .emacs.d
-#+DATE: 2026-07-28 07:21:45 -0500
-
-CORRECTION to the triage-intake.telegram.org write-up sent at 06:15 — supersedes that file with the one just sent.
-
-The root cause and the fix are unchanged and confirmed. Work patched both call sites independently and verified at the wire level: the corrected '(:@type "chatListMain") form survived five consecutive telega--loadChats calls, four on chatListMain and one on chatListArchive, server live at every checkpoint. The bare-symbol form died on the first call.
-
-What was wrong is a secondary claim I made in the gotcha rewrite: that the reported '19 chats of ~50' was truncation caused by this bug. It was not. Work measured 19 before the first load and 19 after all five. Nineteen is the real size of that account, so the overnight sweeps that reported a quiet 19-chat account were accurate readings and nothing was missed.
-
-My own control run had already shown this and I wrote the claim anyway. Three consecutive corrected loads held at 19 here too. If the bad call had been truncating, the corrected call would have loaded more; it did not. I treated a coincidence of numbers as a shared mechanism.
-
-Why it matters enough to send a second file: the truncation framing implies a silent-data-loss mode this evidence does not support. This crash kills a scan outright rather than quietly shortening it, which is a different and less insidious failure. Left standing in the canonical it would have taught every future reader to distrust short chat lists for the wrong reason.
-
-The replacement paragraph states the correction, cites work's measurement, and keeps the still-valid point that ignore-errors catches nothing here because the failure is process death rather than an elisp signal.
-
-Please use the file sent immediately after this note rather than the 06:15 one.