fix(client): snoozed limited threads no longer wake on unrelated activity

[Absterrg0]

Threads snoozed via 'Snooze until reset' reappeared in the inbox before the usage-limit reset time.

The client's raised-hand check compared runtime.updatedAt against snoozedAt, but runtime.updatedAt is projection activity time and advances on unrelated events (title updates, metadata changes). Any background event after the snooze was misread as a fresh failure.

Wake detection now uses the run's stable completedAt timestamp for failed/completed runs, and only falls back to session.updatedAt for legacy session-shaped shells.

Built with Muse Spark via OpenCode.

[macroscopeapp]

🟠 High state/threadSettled.ts:125

A failed production shell with no snoozedAt returns false, so the thread stays hidden until snoozedUntil instead of waking immediately on failure. The fallback only reads shell.session, while production shells populate shell.runtime; include shell.runtime so failures without a completion watermark preserve the server's early-wake behavior.

-  const session = shell.session ?? null;
+  const session = shell.session ?? shell.runtime ?? null;

🤖 Copy this AI Prompt to have your agent fix this:

In file @packages/client-runtime/src/state/threadSettled.ts around line 125:

A failed production shell with no `snoozedAt` returns `false`, so the thread stays hidden until `snoozedUntil` instead of waking immediately on failure. The fallback only reads `shell.session`, while production shells populate `shell.runtime`; include `shell.runtime` so failures without a completion watermark preserve the server's early-wake behavior.

[macroscopeapp]

Approvability

Verdict: Would Approve

Macroscope's review found this PR approvable — This is a narrowly scoped, tested client bug fix that replaces unreliable projection activity timestamps with stable run completion timestamps, preventing unrelated activity from waking snoozed threads. An unresolved High-severity finding remains for runtime-only failures without snoozedAt, which blocks approval until addressed.

Not approved because:

• 1 blocking correctness issue found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}