plan: a parked run tells the terminal nothing actionable — announce where and how to answer it

[Shashankss1205]

What happens

With --approve, a run that parks awaiting a decision announces the request on stdout — but the announcement does not say how to answer it. The operator at the terminal (or the teammate the trace path gets pasted to) has to already know that grapharc approve <trace> exists, that --deny is the other half, and that the wait dies quietly after --approval-timeout (default 300s) with the round counted as unapproved.

Observed while driving a gated run: from the runner's side there is a long silence between the park and either a decision or the timeout, with no line saying what would end it, no countdown, and no pointer to the live view where the parked plan can actually be inspected (serve --live-root shows it grey with awaiting approval).

Why it matters

The approval gate is only as good as the odds a human actually answers it. Today those odds depend on tribal knowledge; the failure mode is a run that silently times out unapproved while its operator stares at a cursor — which then reads as a planner failure, not an unanswered question.

What to consider

• At park time, print one actionable block: the fingerprint, the node list, answer with: grapharc approve <trace> (or --deny), the live-view URL when a live root is configured, and the deadline (waiting up to 300s).
• On timeout, say that the timeout is what happened and repeat the command that would have answered it.
• The Slack path already solves this with its status message; this is about parity for the plain CLI.

Acceptance criteria

A gated run's stdout names the approve command, the fingerprint and the deadline at park time; an unanswered run's final output attributes the stop to the approval timeout; existing approval tests pass unchanged.