feat(web): show and manage subtasks up to three levels deep

This frontend work is blocked by #243 and depends on #349, #368, and #354, so first check that those changes are available. Read the named touchpoints—especially TasksPage, TodosSection, TaskForm, TaskDetailPage, and task-errors.ts—and run the named tests plus the history panel tests. Done means the acceptance criteria pass across task and journal views, with the frontend coverage floor at 80%.

Split from #243 (frontend half). Part of #366.

Waits for the monorepo move (#397), through #243. Blocked by #243 (backend: depth 3, re-parenting, ParentChanged event, upward cascade). Runs after #384 and #387, which replace nested rows with rows and context headers on the Tasks page and journal. Related: #354 (dead error-code cleanup; do it first). #385 also edits task-errors.ts (new TASK_PARENT_STATUS_DERIVED message); rebase onto it.

Problem

Once the API allows subtasks three levels deep and re-parenting (#243), the web app still assumes one level: the parent selectors offer tasks that the server will reject, the history panels do not render the new ParentChanged event, and the error text says "Only one subtask level is supported."

User Story

As a TaskFlow user, I want to see and manage subtasks up to three levels deep in the web app, and to pick only parents that are allowed, so that I can use the deeper nesting and move a task to a different parent without hitting avoidable errors.

Acceptance Criteria

(Numbering in brackets is the criterion's number in the original #243 story.)

1. [7] History display. Given a task with ParentChanged events, when I open the task detail history panel or the journal history modal, then each event is shown with its change summary.
2. Context headers. Given a task with children and grandchildren, when the Tasks page or journal day view renders them, then each work row appears under a context header showing the full path to the top-level goal. There are no nested levels or per-level expand/collapse controls. The Tasks page already does this (#384, PR #390), so only check that it holds at three levels there. The journal part comes from #387.
3. [14] Eligible parents only. Given the parent selectors in the task form, Tasks page and task detail page, when they are opened, then they list only eligible parents: not the task itself, not its descendants, and not tasks that would push the subtree past depth 3. Completed parents follow the rule #368 shipped, which this story keeps: every stored-Completed parent stays in the list as a disabled option with a "(completed)" suffix, whatever the task's own status is (the server still accepts a Completed child under a Completed parent), and an already-selected parent stays enabled. The client-side filter and the server check agree.
4. [15] Error messages. Given a rejected depth request, when the error is shown, then the message names the 3-level limit (it no longer says "one level"). The mapping in task-errors.ts covers only codes the backend emits. It contains no TASK_PARENT_CYCLE_NOT_ALLOWED or TASK_PARENT_INCOMPLETE_CHILDREN (removed by #354) and no new cycle code (#243 adds none).
5. Child count text. Given a child that has its own children, then the "x of y subtasks" text still reads correctly (it shows direct children only, as ChildTaskCount does).

Edge Cases

• Parent dropdowns today offer ineligible tasks (TaskForm, TasksPage, TaskDetailPage). Make the three agree with the server rule through one shared helper. #368 already added it, src/lib/parent-options.ts, used by all three pickers, with a status field on ParentTaskOption, disabled stored-Completed parents with a "(completed)" suffix, and a disabled "Current parent" fallback option when the selected id is missing from the list. Extend that helper with the self, descendant and depth rules; do not create a second helper or a second Completed check. The new ineligible cases are left out of the list, not shown disabled (a default that can be revisited when building); an already-selected parent that becomes ineligible falls back to the "Current parent" option.
• A three-level path has to stay readable in a context header on a phone.
• Pending (undoable) deletes: a pending key on a parent hides its descendants from the read hooks. Check the three-level case.
• Status checks use status === 'Completed' (PascalCase) only.

Out of Scope

• Backend changes (#243).
• MCP changes in nevridge/taskflow-assistant.
• Drag-and-drop re-parenting.
• Bulk subtree move or copy.
• Depth beyond 3.
• A cycle error message (the API never emits a cycle error at depth 3).

Implementation Notes

• Frontend touchpoints: TasksPage, TodosSection, TaskListRow, TaskForm, TaskDetailPage, TaskHistoryPanel and the journal history modal (render the new event type), task-errors.ts.
• The API client is regenerated by the backend-builder in #243. Do not hand-edit sdk.gen.ts or types.gen.ts. Hand-written types in src/api/journal.ts are updated manually.
• Tests to extend, by name: task-errors.test.ts, TodosSection.test.tsx, TasksPage.test.tsx, TaskDetailPage.test.tsx, history panel tests.
• Coverage floor: 80% frontend lines.