fix cloud queue idle recovery

[tatoalo]

Problem

defensive hardening of the idle-recovery path

Changes

• coalesce deferred cloud queue flushes and skip idle recovery while a flush is already scheduled or dispatching

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
apps/code/src/renderer/features/sessions/service/cloudRunIdleTracker.ts:122-134
The JSDoc for `evaluateIdle` still references "`becameIdle`" — a name that no longer exists — and describes the semantics as "flipped the run from not-idle to idle." In practice, `shouldCacheToStore` is `true` whenever the scan path determines `idle === true`, which includes repeated calls while the store hasn't propagated `agentIdleForRunId` yet (e.g., after `markIdle` set the scan state to idle but the live flag is still unset). The description should reflect the actual semantics.

```suggestion
  /**
   * Returns idleness for this exact run. Walks only events added since the
   * previous call so repeated invocations are O(delta), not O(N).
   *
   * The fast path hits `agentIdleForRunId` (the live signal set by the
   * `turn_complete` handler). The scan is a fallback for sessions
   * recreated from logs where the live flag was never set because the
   * no-delta dedup guard skipped reprocessing.
   *
   * `shouldCacheToStore` is true when idleness was determined via the scan
   * path (not the `agentIdleForRunId` fast path). Callers use it to write
   * `agentIdleForRunId` back to the store, avoiding a redundant write when
   * the live flag is already set.
   */
```

_{Reviews (1): Last reviewed commit: "Merge branch 'main' into fix/cloud-queue..." | Re-trigger Greptile}