fix(tasks): refresh active cloud run on task open

[tatoalo]

Problem

After a failed cloud run resumes into a new run, a renderer reload can keep showing the cached failed parent. The task view then remains attached to stale run state until the desktop app is restarted.

Changes

Refresh the authoritative task detail whenever a task view mounts while retaining cached data for immediate rendering. The existing session reconciliation then switches its watcher when the latest run ID changes.

[trunk-io]

😎 Merged successfully - details.

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit 2d0ccba.}

[greptile-apps]

Comments Outside Diff (1)

1. packages/ui/src/features/task-detail/hooks/useTaskData.ts, line 26-27 (link)

   Detail cache shadows live updates

   When a task's latest run changes after the mount-time detail request, the polled task list receives the new run but refreshedTask remains defined and permanently takes precedence. This leaves latest_run-dependent session and cloud state attached to the old run until the detail query is invalidated or the view remounts.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: packages/ui/src/features/task-detail/hooks/useTaskData.ts
   Line: 26-27
   
   Comment:
   **Detail cache shadows live updates**
   
   When a task's latest run changes after the mount-time detail request, the polled task list receives the new run but `refreshedTask` remains defined and permanently takes precedence. This leaves `latest_run`-dependent session and cloud state attached to the old run until the detail query is invalidated or the view remounts.
   
   How can I resolve this? If you propose a fix, please make it concise.

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
packages/ui/src/features/task-detail/hooks/useTaskData.ts:26-27
**Detail cache shadows live updates**

When a task's latest run changes after the mount-time detail request, the polled task list receives the new run but `refreshedTask` remains defined and permanently takes precedence. This leaves `latest_run`-dependent session and cloud state attached to the old run until the detail query is invalidated or the view remounts.

_{Reviews (1): Last reviewed commit: "refactor(tasks): use authoritative task ..." | Re-trigger Greptile}

[stamphog]

Note

🤖 stamphog reviewed 2d0ccbad432e89807769e4084567f8e3ce32e057 — verdict: REFUSED

Greptile flagged a substantive, unaddressed P1 concern: the new hook fetches the task detail once on mount (no refetch interval), so once populated it permanently shadows the live-polled task list — meaning after the initial mount, later run-status changes (the exact scenario this PR is meant to fix) stop propagating to the view until it remounts. The diff shows no follow-up commit addressing this.

• Author wrote 0% of the modified lines and has 7 merged PRs in these paths (familiarity MODERATE).
• 👍 on the PR from greptile-apps[bot].
• Unresolved/unaddressed Greptile P1 comment on useTaskData.ts: detail-query data has no refetch interval and takes precedence over the polled task list indefinitely once fetched, so live run-status updates stop reaching the view after mount until it remounts or the query is otherwise invalidated.

Gate mechanics and policy version

Gate		Result
prerequisites	✓	all clear
deny-list	✓	no deny categories matched
size	✓	23L, 2F substantive, 80L/3F incl. docs/generated/snapshots — within ceiling
tier	✓	T1-agent / T1b-small (80L, 3F, single-area, fix)
stamphog 2.0.0b3		.stamphog/policy.yml @ dec9229 · reviewed head 2d0ccba