fix(triage): pass the TL object to loadChats, not a bare symbol

Step 1 called (telega--loadChats 'main). That's a raw TL wrapper, so it drops its argument into the request as :chat_list untouched. The symbol went out on the wire as main, and the C parser aborts on any value it can't start. Every telegram sweep has been killing telega-server. Both call sites now pass '(:@type "chatListMain"), which is what telega's own callers use.

I merged this with the down-is-launch fix parked since 2026-07-24 rather than applying either alone. The parked file still carried the bad call, and its new prose cited the segfault gotcha as the reason docker mode is mandatory. That's the same gotcha this rewrites to say the deaths were our own bad argument. Shipping them in sequence would have left the file arguing against itself, so I reconciled the prose in both places and kept the docker requirement on its own evidence.

The gotcha keeps two caveats. A crash with no triage verb running needs its own investigation. And a short chat list is a real short list, because 19 was the true account size measured at both ends, not a scan truncated by this bug.

1 files changed, 17 insertions, 0 deletions

diff --git a/working/triage-telegram-segfault-rootcause/note-0721-correction.org b/working/triage-telegram-segfault-rootcause/note-0721-correction.org
new file mode 100644
index 0000000..73e9274
--- /dev/null
+++ b/working/triage-telegram-segfault-rootcause/note-0721-correction.org
@@ -0,0 +1,17 @@
+#+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.