feat: Show PR and diff status icons on task list items

[charlesvien]

Problem

Task sidebar icons show session state (suspended, paused) which isn't useful at a glance. Users want to see work state: PR merged/open/draft/closed, uncommitted changes, or idle.

Changes

1. Add useTaskPrStatus hook that queries PR state and diff stats per task using existing tRPC procedures
2. Update icon priority chain in TaskItem to show GitMerge (purple), GitPullRequest (green/gray/red), or GitBranch (amber) based on task state
3. Extend TaskData with folderPath, cloudPrUrl, branchName, linkedBranch for the hook to consume
4. Skip diff/sync queries when PR already exists or task lacks a worktree (performance optimization)
5. Use useMemo with stable EMPTY reference to prevent unnecessary re-renders

How did you test this?

Manually

[charlesvien]

• fix: Downscale large images before attaching #1987
• feat: Show PR and diff status icons on task list items #1986 👈 (View in Graphite)
• fix: Reduce update check interval from 24h to 1h #1985
• fix: Debounce releases and skip empty tags in code workflow #1983
• fix: Fix stacked chevrons in project select dropdowns #1981
• fix: Enrich attachment-only task descriptions for title generation #1980
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[greptile-apps]

Prompt To Fix All With AI

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

---

### Issue 1 of 3
apps/code/src/renderer/features/sidebar/hooks/useTaskPrStatus.ts:82-84
**Transient "Has changes" flicker for tasks with `linkedBranch`**

When a task has `linkedBranch` set, the `getPrUrlForBranch` query fires but `linkedBranchPrUrl` starts as `undefined` while loading. During that window `knownPrUrl = false`, so `skipDiff = false` and the diff/sync queries run immediately. If those resolve first (likely for local git ops vs. a GitHub API call), `hasDiff` becomes `true` and the amber GitBranch icon flashes briefly before the linked PR status arrives. Adding `!!linkedBranch` to the skip condition would suppress diff queries for this case:

```typescript
const skipDiff = isCloud || !hasWorktree || knownPrUrl || knownLocalPr || !!linkedBranch;
```

The trade-off is that if `getPrUrlForBranch` returns no URL (no PR exists for the branch), `hasDiff` would stay `false`; if showing diff state for branch-less linked tasks is desired, a follow-up pass after `linkedBranchPrUrl` resolves to `null` could re-enable it.

### Issue 2 of 3
apps/code/src/renderer/features/sidebar/hooks/useTaskPrStatus.test.ts:78-93
**Index-based query mock is silently fragile**

The `queryCallIndex` counter hard-codes the assumption that `useQuery` is always called in exactly this order: `[cloudPrDetails, linkedBranchPrUrl, linkedPrDetails, localPrStatus, diffStats, syncStatus]`. If the hook ever gains a new query, reorders calls, or uses a conditional query, all the derivation tests would silently test the wrong data — passing with incorrect assertions. Consider a named/keyed mock (matching on `queryKey`) so the mock remains correct regardless of call order.

### Issue 3 of 3
apps/code/src/renderer/features/sidebar/hooks/useTaskPrStatus.test.ts:152-188
**Prefer parameterised tests for `mapPrState`**

Per project convention, multiple expectations testing the same function with different inputs should use `it.each`. Currently several tests in the `mapPrState` describe block bundle multiple `expect` calls inside a single `it`, which hides individual failure cases and bypasses idiomatic parameterisation. For example:

```typescript
it.each([
  ["open",   true,  false, "merged"],
  ["OPEN",   true,  false, "merged"],
  ["closed", true,  false, "merged"],
  [null,     true,  false, "merged"],
] as const)(
  "mapPrState(%s, merged=%s, draft=%s) → %s",
  (state, merged, draft, expected) => {
    expect(mapPrState(state, merged, draft)).toBe(expected);
  },
);
```

The same pattern applies to the `closed`, `draft`, and `open` cases.

_{Reviews (1): Last reviewed commit: "Remove comments and add derivation tests" | Re-trigger Greptile}

[jonathanlab]

LGTM.

nit: Not too big of a fan of doing all this in a hook, should probably just happen inside it's own service tbh.