Blocked tasks are a dead end in the Web UI: no blocker question, no resolve/waive actions

## What

When a task is blocked, the task page offers only "open session" and "cancel". The blocker's question is invisible and there is no way to answer it (resolve) or waive a failed dependency. Worse, the blocker resolution is never fed back to the agent: the next worker run rebuilds the prompt from title+description only, so even a resolved blocker's answer is lost and the agent re-asks.

## Why

The agent blocks tasks with user_input / external_dependency questions (`agent_task_blocker.question`), and the inbox routes users to the task page — which dead-ends. The CLI path (`stella task blocker resolve`) sends an empty resolution and `task get` only prints the blocker ID, so no surface completes the ask→answer→resume loop.

## How

- API: add `GET /api/tasks/{taskId}/blockers/{blockerId}` returning the blocker (kind, status, question, detail, resolution, timestamps).
- Backend: inject the latest resolved blocker's question+resolution into the next worker run prompt (skip empty/`{}` resolutions).
- Web: on blocked tasks show the blocker question, a resolution input + resolve action; for dep_failure blockers list failed deps with a waive action (reason required).

## Refs

- Follow-up to #367 QA; related to #368

Start by tracing the existing task API routes, the blocked-task Web UI, and the worker prompt construction; compare these with the CLI entry point `stella task blocker resolve` and `task get`. Done means the blocker question and resolution flow works for user-input and dependency-failure blockers, and resolved answers reach the next worker run without empty resolutions.

Written by the indexing model from the issue text.