Feature: Support subtasks, checklists, and task dependencies

## Summary

Add hierarchical task breakdown and explicit dependency relationships so larger work can be planned and completed in stages.

## Problem / Opportunity

Every TaskNexus item is currently a flat, independently completable task. Users cannot represent a parent outcome, track its component steps, or indicate that one task is blocked by another. This encourages oversized task descriptions and hides actionable progress.

## Proposed Feature

Allow tasks to contain ordered subtasks/checklist items and optionally depend on other tasks. Show parent progress and blocked state, provide clear completion rules, and preserve correct behavior under realtime updates and drag reordering.

## Scope

- Design a schema for parent-child relationships, ordering, and directed dependencies.
- Enforce ownership, referential integrity, maximum supported nesting, and cycle prevention.
- Extend TaskContext validation and mutations for hierarchical realtime updates.
- Add expand/collapse, progress, blocked indicators, and accessible editing workflows.
- Define how parent completion, child completion, deletion, and reparenting interact.
- Add migration and API/data-model documentation.

## Acceptance Criteria

- [ ] Users can add, edit, reorder, complete, and delete subtasks from a parent task.
- [ ] The supported nesting depth is documented and enforced consistently.
- [ ] A parent displays deterministic progress derived from its children.
- [ ] Users can add and remove dependencies between tasks they own.
- [ ] Cyclic dependencies and invalid cross-user references are rejected.
- [ ] Blocked tasks are visually and semantically identifiable without relying only on color.
- [ ] Completion and deletion rules are confirmed in destructive flows and covered by tests.
- [ ] Realtime events keep expanded hierarchies and dependency states correct on multiple clients.
- [ ] Screen-reader focus and announcements remain coherent when rows expand, move, or change status.
- [ ] Documentation includes the data model, invariants, and representative workflows.

## Non-Goals

- General-purpose project scheduling or critical-path optimization.
- Cross-account dependencies.
- Arbitrarily deep trees.

## Dependencies / Risks

- Recursive relationships complicate ordering, cascade behavior, and realtime reconciliation.
- Parent progress can drift if mutations are not transactional or derived consistently.
- Drag-and-drop gestures must coexist with expand/collapse and assistive interaction.

## Open Questions

- Should completing a parent complete all remaining children, be blocked, or prompt the user?
- Are checklist items lightweight records or full tasks with all task metadata?
- What maximum hierarchy depth balances utility and UI clarity?