Backend + dashboard: distinguish 'waiting for human' from generic Waiting status

[chaizhenhua]

Context

PR #222's Workload card treats waiting > 0 as the human-action signal — warn-tinted card, aria-live announcement, "Action needed" prefix. This works on today's backend because RunStatus::Waiting is only emitted by the HITL gate.

Problem

The reviewer flagged that "waiting" is a coarse status — future RunStatus variants (queued for backpressure, paused, finalizing, awaiting tool reply, etc.) may also map to Waiting or live alongside it. Frontend can't keep this distinction by guessing; the backend should expose it.

Proposal

Backend changes:

1. Add a waiting_for_human: usize field to the RunsSummary wire shape (/v1/runs/summary). For now it can be implemented as a count of runs with RunStatus::Waiting and a non-null waiting_for_decision or equivalent HITL marker.
2. Keep waiting as the existing total (for backwards compat) but document that HITL UIs should read waiting_for_human instead.

Frontend changes (this PR or follow-up):

1. WorkloadCard switches the HITL hero state to key off waiting_for_human > 0 instead of waiting > 0. Falls back to today's behavior when the field is absent (older server build).
2. A regular "waiting" count still appears in the sub-line, but doesn't trigger the warn tone or aria-live announcement.

Acceptance

• RunsSummary wire ships a new optional waiting_for_human field
• WorkloadCard tints warn iff waiting_for_human > 0 (or falls back when missing)
• Test: a run in Waiting not awaiting human input doesn't trigger the action-needed banner

Notes

PR #222's current behaviour is documented as best-effort in the WorkloadCard's source comment. This issue is the path to making it correct.