feat: add blocked for human input feature

[CaitlynByrne]

Summary

• Agents can now request structured human input when they encounter genuine blockers (API keys, design choices, external configs)
• The request is displayed in the UI with a dynamic form, and the human's response is stored and made available when the agent resumes
• Full stack implementation spanning database, MCP server, API, orchestrator, and UI (21 files changed, 1 new component)

Key changes

• Database: 3 new columns (needs_human_input, human_input_request, human_input_response) with migration
• MCP: New feature_request_human_input tool + guards on existing tools
• API: New resolve-human-input endpoint, 4th feature bucket
• Orchestrator: Skip needs_human_input features in scheduling
• Progress: 4-tuple return from count_passing_tests
• WebSocket: needs_human_input count in progress messages
• UI: Conditional 4th Kanban column, HumanInputForm component, amber status indicators, dependency graph support

Test plan

• Start the agent, verify features needing human input show in a 4th "Blocked" Kanban column
• Submit human input via the form and verify the feature resumes
• Verify dependency graph renders blocked features with amber indicators
• Confirm orchestrator skips blocked features and continues with others
• Run ruff check . and cd ui && npm run build to verify lint/type checks pass

🤖 Generated with Claude Code

[leonvanzyl]

Thanks for the thoughtful full-stack implementation here. This is a strong direction overall and the feature is very useful.

I found a few issues that should be addressed before merge:

1. Graph view cannot open "Needs Input" features

• In ui/src/App.tsx, handleGraphNodeClick still only searches pending/in_progress/done.
• Please include needs_human_input there so blocked nodes can be opened and resolved from graph mode.

2. Human input field validation is too permissive (backend)

• In mcp_server/feature_mcp.py (feature_request_human_input), validation currently only checks id/label.
• Please validate field schema more strictly (allowed type, required options for select, unique/non-empty IDs), so malformed requests cannot be created.

3. Progress fallback undercounts total features

• In ui/src/App.tsx, the non-WebSocket fallback total excludes needs_human_input.
• Please include it so fallback progress is not misleading during reconnect/initial load.

If you can patch these, this should be in good shape to merge. Appreciate the work on this.