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, 10 insertions, 10 deletions

diff --git a/todo.org b/todo.org
index 867b920..893ca6e 100644
--- a/todo.org
+++ b/todo.org
@@ -133,26 +133,26 @@ The proposed Claude-memory migration auditor is related only by runtime portabil
 
 No prepared diff: this is a shared configuration design decision, and the current local wrappers/configs remain machine-owned evidence rather than canonical source. Say "spec the MCP registry sync" to start the decisions walk.
 
-** VERIFY [#B] Parked: telegram source treats "down" as launch, not SCAN FAILED (from .emacs.d)
+** DONE [#B] Parked: telegram source treats "down" as launch, not SCAN FAILED (from .emacs.d)
+CLOSED: [2026-07-28 Tue]
 :PROPERTIES:
 :LAST_REVIEWED: 2026-07-24
 :END:
-What arrived: a superseding handoff (the 17:23 setq-only version is retained as context but not the one to take). Both work and home independently hit the same failure — the telegram source, finding telega down or unloaded (its *normal* entry state), reported "SCAN FAILED: telegram — not loaded" or ran a blind sweep, instead of running Step 1 to launch it. Neither hit a segfault. The recovery IS Step 1: =(telega t)= both loads the package and starts the docker server.
+Applied 2026-07-28, merged with the segfault root-cause fix that arrived the same morning rather than applied alone.
 
-Root cause is wording, not code: the Quick Reference said "never skips because the server is down" but the closing paragraph said "if any lifecycle step fails ... reports SCAN FAILED", and two agents conflated "server is down" with "a lifecycle step failed" → blind sweep without ever attempting the launch.
+Merging was necessary, not tidiness. The parked proposed file still carried the bad =(telega--loadChats 'main)= call at its own lines 52 and 122, so applying it as-is would have shipped a file that fixed the wording defect while preserving the call that kills the server. Its third hunk also added prose citing "tdlib segfaults in native mode (SEGFAULT gotcha below)" — pointing at the section the new handoff rewrites to say those deaths were our own bad argument, not tdlib memory corruption.
 
-The fix (33-line diff, verified present): a directive after the Quick Reference that down/not-loaded is the *trigger* to launch, never a skip; the =:ENABLED:= guard tests whether telega is *installed* (=fboundp=), not whether the server is up; SCAN FAILED reserved for a launch that was attempted and didn't reach Ready; a note that a blind sweep is worse than a clean failure because it hides real unread behind a false all-clear. Also keeps the earlier =(setq telega-use-docker t)= segfault guard in Step 1 — both projects confirmed it's a real latent guard though not the cause here.
+What landed: all three parked hunks (the down-is-launch directive, the SCAN-FAILED-only-after-launch-attempted rewording, the =(setq telega-use-docker t)= restored to the Step 1 code block), plus both corrected =loadChats= call sites and the rewritten gotcha. The native-mode prose was reconciled in two places so it no longer leans on the refuted story: the Step 1 comment now states plainly that docker mode and the loadChats bug are separate concerns (the deaths happened *in* docker mode, so docker mode is neither a defense against it nor evidence for it), and the Quick Reference line says "crashed in native mode (2026-06-09)" instead of "segfaults", with the same disambiguation.
 
-Recommendation: accept the superseding version. The wording defect is real and reproduced by two projects, and a triage source silently reporting all-clear on a mailbox it never scanned is exactly the false-negative class that matters.
+Verified: both live call sites use the TL object; the two remaining ='main= occurrences are inside the gotcha prose describing the bug. lint-org clean, mirror synced, suite green.
 
-Prepared: [[file:working/triage-telegram-down-launch/proposed.diff]] and the full proposed file beside it.
-Say "approve the parked telegram fix" and it gets applied.
-
-*** VERIFY a SCAN FAILED source must not advance its sentinel (engine, not the plugin)
+** VERIFY [#B] A SCAN FAILED source must not advance its sentinel (engine, not the plugin)
 :PROPERTIES:
 :LAST_REVIEWED: 2026-07-24
 :END:
-Secondary finding from the same handoff, flagged for your judgment because it's *engine* behavior in =triage-intake.org=, not the telegram plugin. work reported that after a SCAN FAILED, "the marker still advanced" — and telegram is =:ANCHOR: none=, so something advanced a cursor it shouldn't have. The compounding harm: a source that reports SCAN FAILED but advances its window means the next sweep believes it already covered that window, so the blind-sweep hole persists across sweeps rather than self-healing. Not touched .emacs.d-side; needs a look at the engine's per-source last-run/anchor advance.
+Promoted to top-level 2026-07-28 when its parent closed — it is a separate engine question and would have been buried under a DONE parent.
+
+Secondary finding from the 2026-07-24 handoff, flagged for your judgment because it's *engine* behavior in =triage-intake.org=, not the telegram plugin. work reported that after a SCAN FAILED, "the marker still advanced" — and telegram is =:ANCHOR: none=, so something advanced a cursor it shouldn't have. The compounding harm: a source that reports SCAN FAILED but advances its window means the next sweep believes it already covered that window, so the blind-sweep hole persists across sweeps rather than self-healing. Not touched .emacs.d-side; needs a look at the engine's per-source last-run/anchor advance.
 
 ** TODO [#B] cj-remove-block still can delete the WRONG cj block :bug:
 :PROPERTIES: