tasks: a blocked card names its approvals but cannot show or decide them — the board never got #1002's fix #1891

A paused board card says it is waiting on approvals. It cannot say what they are, and it cannot decide them.

taskApprovalBlock (frontend/src/lib/task-approvals.ts) already hands the card the full ApprovalSummary[] — payload, amount_usd, group, agent, expires_at_millis. BlockedRow (frontend/src/views/TaskCard.tsx) reads count and at_millis and drops the rest:

Fetch a web page
Waiting for your approval · 4m ago          Review

The detail screen is the same shape one line long — AwaitingApprovalRow (frontend/src/views/TaskDetailView.tsx) prints Waiting on your approval — fetch a web page and a link.

This is the complaint #1002 already answered one surface over. The run drawer told an operator their run had parked and gave them nowhere to act, so deciding meant leaving the run, finding the row in a flat queue, and coming back. run-approvals.ts + an inline ApprovalRow fixed it there. The task board is the blocker surface that never got the same treatment, and it is the one an operator actually works from.

What is dropped

Three fields, and each is a distinct failure:

1. The payload lead. Two cards blocked on http_request read identically, so the card cannot distinguish a GET of a docs page from a DELETE against production. payloadLeadLabel is the function chat uses for exactly this and is already imported one directory over.
2. group. The consequence chip — spend / send / sign / publish — is what tells an operator whether this is worth interrupting themselves for. The card renders no signal at all, so a payment.send and a file read are the same pixels.
3. expires_at_millis. The card counts up from the park (waiting 4m) and never counts down to the deadline. An approval that default-denies on [policy].approval_ttl_hours gives the board no warning before it does — the operator's first news of the expiry is the work not having happened. Every other approval surface paints this; the board does not.

Proposed fix

Do not re-implement deciding. ApprovalRow (frontend/src/views/chat/ApprovalRow.tsx) owns it: batch all-or-nothing over pending, per-id resolve so each approved call still mints its own revocable grant (#739), detached POST (#391), the busy / failed / partially-settled states, role redaction (#618), and the needsFullReview rule that pulls Approve when the payload lead is truncated. A hand-rolled row on the card would lose the last two silently.

1. A third layout on ApprovalRow, not a fork. A board column is w-65 — roughly 220px of card content — so CompactApprovalRow's horizontal flex does not fit. variant="card" is the same content stacked: action + lead, then consequence chip and deadline, then Approve/Decline as a full-width pair. Plus a detailsHref prop, since the two hardcoded #/approvals links inside it should address #/approvals/<taskId> from here. Defaults leave chat byte-identical.
2. taskApprovalRows() in lib/task-approvals.ts, mirroring runApprovals(): the live queue joined with the shell's witnessed decided map, so a row settles in place across the gap between the resolve's answer and the feed's next poll rather than blinking out.
3. Thread the decide bundle the way WorkflowsView already receives it in app-shell.tsx — decidingApprovals / decidedApprovals / failedApprovals / onDecideApproval — through LedgersView → BoardMode → TaskItem, and through TaskDetailRoute → TaskDetailView (which already receives parked).
4. The detail screen gets the full card, one ApprovalRow per approval as RunApprovalsSection does. There is room there for the payload preview and the grant-scope control.

Constraints this must not break

• Resume stays disabled while the card is blocked (console: a paused card never says which approvals block it, and Resume re-parks it #883). Unchanged, and still correct: since approvals: a turn that parks several calls never answers — each approval re-runs the turn independently, and the chat count never clears #469 the last decision continues the turn on its own, so re-dispatching only re-runs the work and parks it again.
• The detail screen's ownership rule survives. AwaitingApprovalRow deliberately treats the host-computed approvals as the truth for whether the card is waiting and the parked queue only for naming, because approval_owner has an attempt-level key the console cannot see. So the decidable rows cover the id-matched subset and any residual keeps its own line — a decide surface must never imply it covers approvals it cannot see.
• No new request and no new wire field. Both surfaces read the approvals feed the sidebar badge already polls, exactly as console: a paused card never says which approvals block it, and Resume re-parks it #883 established.

Tests

Extending frontend/test/unit/task-blocked-card.test.ts and task-approvals.test.ts: the card names the payload lead rather than the kind; the chip and the countdown render; Approve fires onDecide once per id; a truncated lead swaps Approve for the details link; a witnessed decision settles the row in place; the detail screen's residual line appears when the queue has not delivered every pending approval.