feat(sidebar): add "By status" organize mode

[fercgomes]

Summary

Adds a third By status option to the sidebar's organize menu (alongside By project and Chronological list). Tasks are bucketed into kanban-like collapsible sections by their lifecycle state — narrow enough to fit in the sidebar, but conceptually a vertical kanban.

Buckets in fixed precedence + display order:

1. Needs you — needsPermission
2. Active — isGenerating OR taskRunStatus ∈ {queued, in_progress}
3. Done — taskRunStatus === "completed"
4. Failed — taskRunStatus ∈ {failed, cancelled}
5. Idle — everything else (no run, not_started, etc.)

A task lands in the first bucket whose predicate matches, so e.g. an in-progress run that needs permission shows under "Needs you", not "Active".

Empty buckets are hidden. Each section reuses the existing collapsedSections persistence in sidebarStore, so collapse state survives reloads.

Test plan

• pnpm --filter code typecheck clean
• New unit tests in groupByStatus.test.ts cover bucket assignment, precedence (Needs-you > Active), display ordering, empty input, and intra-bucket order — all 5 pass
• All existing sidebar tests still pass (36/36)
• Open the funnel menu, pick By status — verify sections render in the fixed order with status-colored icons
• Confirm sections collapse/expand independently and state persists after reload
• Switch between By project / By status / Chronological and back — verify no layout glitches
• Verify pinned tasks still appear in the top "Pinned" section across all modes
• With no tasks, the empty-state hedgehog still renders

[greptile-apps]

Prompt To Fix All With AI

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

---

### Issue 1 of 2
apps/code/src/renderer/features/sidebar/utils/groupByStatus.test.ts:16-55
**Tests not parameterised**

The team rule is "we always prefer parameterised tests." The bucket-assignment test and the order-preservation test verify one case at a time inside a single `it` block. When a single bucket predicate regresses the failure message points at one giant assertion block rather than at the exact `(input → expected bucket)` pair that broke. Using `it.each` here would also make the "preserves input order" test cover all buckets rather than only `completed`.

For example, bucket assignment could be expressed as `it.each([[{ taskRunStatus: "in_progress" }, STATUS_GROUP_IDS.active], ...])("routes task to correct bucket", (props, expected) => { ... })`.

### Issue 2 of 2
apps/code/src/renderer/features/sidebar/components/TaskListView.tsx:410-429
**TaskRow JSX duplicated across render branches**

The `TaskRow` block here (11 props, same shape) is byte-for-byte identical to the one in the `by-project` branch (lines 479–498) and very close to the chronological and pinned branches. Per the OnceAndOnlyOnce simplicity rule, extracting a small helper — e.g. `renderTaskRow(task, { depth, timestampKey, activeTaskId, ... })` — would let all four branches share one call site and reduce the surface area for future prop additions to miss a branch.

_{Reviews (1): Last reviewed commit: "style(sidebar): apply biome formatting" | Re-trigger Greptile}

[greptile-apps]

Tests not parameterised

The team rule is "we always prefer parameterised tests." The bucket-assignment test and the order-preservation test verify one case at a time inside a single it block. When a single bucket predicate regresses the failure message points at one giant assertion block rather than at the exact (input → expected bucket) pair that broke. Using it.each here would also make the "preserves input order" test cover all buckets rather than only completed.

For example, bucket assignment could be expressed as it.each([[{ taskRunStatus: "in_progress" }, STATUS_GROUP_IDS.active], ...])("routes task to correct bucket", (props, expected) => { ... }).

Context Used: Do not attempt to comment on incorrect alphabetica... (source)

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/code/src/renderer/features/sidebar/utils/groupByStatus.test.ts
Line: 16-55

Comment:
**Tests not parameterised**

The team rule is "we always prefer parameterised tests." The bucket-assignment test and the order-preservation test verify one case at a time inside a single `it` block. When a single bucket predicate regresses the failure message points at one giant assertion block rather than at the exact `(input → expected bucket)` pair that broke. Using `it.each` here would also make the "preserves input order" test cover all buckets rather than only `completed`.

For example, bucket assignment could be expressed as `it.each([[{ taskRunStatus: "in_progress" }, STATUS_GROUP_IDS.active], ...])("routes task to correct bucket", (props, expected) => { ... })`.

**Context Used:** Do not attempt to comment on incorrect alphabetica... ([source](https://app.greptile.com/review/custom-context?memory=instruction-0))

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

TaskRow JSX duplicated across render branches

The TaskRow block here (11 props, same shape) is byte-for-byte identical to the one in the by-project branch (lines 479–498) and very close to the chronological and pinned branches. Per the OnceAndOnlyOnce simplicity rule, extracting a small helper — e.g. renderTaskRow(task, { depth, timestampKey, activeTaskId, ... }) — would let all four branches share one call site and reduce the surface area for future prop additions to miss a branch.

Context Used: Do not attempt to comment on incorrect alphabetica... (source)

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/code/src/renderer/features/sidebar/components/TaskListView.tsx
Line: 410-429

Comment:
**TaskRow JSX duplicated across render branches**

The `TaskRow` block here (11 props, same shape) is byte-for-byte identical to the one in the `by-project` branch (lines 479–498) and very close to the chronological and pinned branches. Per the OnceAndOnlyOnce simplicity rule, extracting a small helper — e.g. `renderTaskRow(task, { depth, timestampKey, activeTaskId, ... })` — would let all four branches share one call site and reduce the surface area for future prop additions to miss a branch.

**Context Used:** Do not attempt to comment on incorrect alphabetica... ([source](https://app.greptile.com/review/custom-context?memory=instruction-0))

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!