[BUG] Scheduled task dispatch acknowledged by renderer but no session starts; 'Cleared stale pending dispatch' after 12 min, lastRunAt stamped anyway (3 of 18 tasks lost overnight)

Thank you for the desktop scheduler — running ~60 unattended tasks a day on it has genuinely changed how I work, and the recent `lastRunAt`/`nextRunAt` visibility in the task list is appreciated.

## What happened

A scheduled task is dispatched, the renderer acknowledges it, **no session is ever started**, and ~12 minutes later the main process logs `Cleared stale pending dispatch`. `lastRunAt` is stamped anyway, so the task list shows the task as having run. On one night this hit 4 of 18 dispatches; 3 of them never ran at all.

`~/Library/Logs/Claude/main.log`, 2026-09-08 (local time), redacted only to task names:

```
03:12:59 [info] [CCDScheduledTasks] Spawning new session for scheduled task voc-weekly-incremental {...}
03:12:59 [info] [CCDScheduledTasks] Dispatch acknowledged by renderer: voc-weekly-incremental
03:21:00 [warn] [CCDScheduledTasks] Cleared stale pending dispatch for: voc-weekly-incremental
(no "Starting local session" for that task's folder all night; lastRunAt now shows 2026-09-08T09:21:00Z)

03:36:05 ... Spawning new session for scheduled task daily-reading
03:36:05 ... Dispatch acknowledged by renderer: daily-reading
03:51:00 [warn] Cleared stale pending dispatch for: daily-reading (never ran)

04:28:23 ... Spawning new session for scheduled task singularity-research-weekly
04:28:23 ... Dispatch acknowledged by renderer: singularity-research-weekly
04:40:00 [warn] Cleared stale pending dispatch for: singularity-research-weekly (never ran)

08:35:27 [info] Delaying dispatch for morning-checkin-daily by 265s (jitter)
08:39:52 ... Spawning new session for scheduled task morning-checkin-daily
08:39:52 ... Dispatch acknowledged by renderer: morning-checkin-daily
08:51:27 [warn] Cleared stale pending dispatch for: morning-checkin-daily
09:51:41 [info] Confirmed task run for: morning-checkin-daily (started 72 min late, on its own)
```

A healthy dispatch on the same night is the triple `Spawning new session` → `Dispatch acknowledged by renderer` → `Confirmed task run` within ~1 s (14 of 18 did this).

The same `Cleared stale pending dispatch` warning also appears in this log on 2026-08-29 (`ig-publish-daily` and a one-time task, 3×) and 2026-08-31 (`early-run-sunday-weekly`, which likewise stamped `lastRunAt` with no session created).

## Environment

- Claude desktop app 1.46388.4 (Code tab), Claude Code 2.1.260, macOS 26.x (Darwin 25.6.0), Apple silicon
- Laptop awake, on AC power the whole time; app running since the previous evening; no sleep/wake events near the 03:xx or 08:3x dispatches (checked `pmset -g log`)
- Interactive sessions were open in other folders at 08:39 (one actively running)
- Also visible the same night: `Skipping dispatch for : global_limit (active=3, limit=3)` for ~9 consecutive minutes — the concurrency cap in #91387. The lost dispatches above were *not* skipped by that cap; they were acknowledged and then went nowhere.

## Expected

Either the acknowledged dispatch starts a session, or the stale-clear re-dispatches it promptly (the 08:39 one eventually did, 60 min after the clear; the three overnight ones never did). `lastRunAt` should not advance for a run that never created a session — for a daily task that makes a lost run invisible until someone reads the log.

## Impact / workaround

Three daily/weekly tasks silently produced nothing, and the task list reported them as run. I now grep the log every morning for `Cleared stale pending dispatch` and re-fire any lost task as a one-time task.

Happy to share the full log excerpt or run a debug build if that helps.

Start with the CCDScheduledTasks dispatch flow and the corresponding entries in ~/Library/Logs/Claude/main.log. Compare acknowledged dispatches with the later Confirmed task run and Cleared stale pending dispatch events, including the global_limit context. Done means an acknowledged dispatch reliably starts a session or is promptly retried, and lastRunAt does not advance when no session is created.

Written by the indexing model from the issue text.