Add task blockers and ready-work discovery for agents #76

Outcome

Agents can select executable work and understand why other tasks must wait.

Semantics

• Parent/subtask means decomposition; it does not order siblings.
• blocked_by means a prerequisite must be satisfied before work is ready.
• related is informational; discovered_from records where follow-up work originated.
• Open, unassigned work with satisfied prerequisites is the default ready queue; owned in-progress work is reported separately.
• Manual blocked status remains meaningful without a dependency edge.
• A canceled prerequisite is not automatically a successful prerequisite; document an explicit waive/remove/replacement action.

Dependencies

Use the shared public item/reference foundation and relation conventions from the link-graph epic. Initially support task blockers within one project.

Acceptance

• Reject self-links and dependency cycles, including concurrent changes.
• A blocked task is absent from ready results with an authorized explanation available.
• Claim checks eligibility and assignment atomically; two agents cannot both acquire the same task.
• Completion/reopening/dependency changes refresh readiness without silently starting tasks.
• Existing parent completion constraints remain effective.
• MCP tools, short descriptions and session recall explain ready work and preserve permissions/version checks.

Reference

Beads inspiration: https://github.com/gastownhall/beads/blob/main/docs/index.md

Agent handoff

Planning only. Ready queue is a recommendation/eligibility service, not an autonomous execution scheduler.

Concrete subtasks

1. #92 Dependency semantics (after #79; coordinate #88).
2. #93 Blocker persistence/cycle prevention (after #88, #89, #92).
3. #94 Ready queries and atomic claim (after #93).
4. #95 Ready filter/blocker UI (after #94).
5. #96 Agent handoff/docs and integration acceptance (after #82 and #94).

Technical dependencies are recorded in Markdown until the blocker feature itself exists.