Run status should report what the run is waiting for

Start with src/Runtime/class-wp-agent-chat-run-control.php and src/Channels/register-agents-chat-run-control-abilities.php; read normalize_run(), agents_chat_run_output_schema(), and the runtime-tool and pending-action entry points. Done means blocked runs expose verifiable required_actions IDs scoped to their run, non-blocked runs expose an empty list, and pending-action filtering supports run_id; verify the four required scenarios in the issue.

Problem

Two run statuses mean the run is blocked and waiting on someone: runtime_tool_pending and approval_required. The run payload says the run is blocked. It does not say what to act on.

A client that polls agents/get-chat-run and sees approval_required has to already know which subsystem blocked the run, then go find the row itself. For approvals there is no canonical way to do it: the pending-action list takes implementation-defined filters, so scoping by run is up to each store. The caller that is supposed to unblock the run cannot get from the run to the thing that unblocks it.

Evidence

• src/Runtime/class-wp-agent-chat-run-control.php — STATUS_RUNTIME_TOOL_PENDING and STATUS_APPROVAL_REQUIRED are canonical statuses.
• src/Channels/register-agents-chat-run-control-abilities.php — agents_chat_run_output_schema() returns run_id, session_id, status, timestamps, and opaque metadata. Nothing about what the run is waiting for.
• agents/resolve-pending-action requires an action_id, and agents/submit-runtime-tool-result requires a request_id. Neither id is reachable from the run payload.
• agents_pending_action_filters_input_schema() documents its filters as implementation-defined, so run scoping is not part of the contract. agents/list-runtime-tool-requests does accept run_id, which is the shape to follow.

Required contract

• Add an optional required_actions array to the canonical run payload, normalized in WP_Agent_Run_Control::normalize_run() so every run family gets it.
• Each entry names the kind of action and the id to act on. Cover runtime_tool_result and pending_action first, and leave the kind open for other blocking sources.
• Populate it whenever the status is a blocked status, and leave it empty otherwise. A store that cannot supply it returns nothing rather than an invented entry.
• Add a canonical run filter to the pending-action list so the entry can be verified against a query.

Tests

• A run blocked on a runtime tool exposes an entry whose id is accepted by agents/submit-runtime-tool-result.
• A run blocked on an approval exposes an entry whose id is accepted by agents/resolve-pending-action.
• Running and completed runs expose an empty list.
• Two runs blocked in the same session never see each other's entries.