feat(task): follow a task run to completion with --wait

[pat-s]

ricochet task invoke --wait now follows a task run until it finishes and exits non-zero unless it succeeded, and ricochet task invocation get reads one run on demand.

AI Summary

Behaviour

• ricochet task invoke <ID> --wait (-w) checks the run every 2 seconds until it leaves pending, prints the finished run, and exits 1 when it ended as failure or cancelled. With -F json or -F yaml, stdout carries only the finished run.
• A status check that meets a connection error, timeout, or 5xx response is retried every 2 seconds for up to 30 seconds. Each check times out after 10 seconds, so a stalled server ends the wait within about 45 seconds. A 4xx still fails at once.
• When waiting fails, the error names the run and the ricochet task invocation get <ID> <INVOCATION_ID> command to check it later.
• ricochet task invocation get <ID> <INVOCATION_ID> prints one run, finished or not. It takes the content ID as well as the invocation ID, because the server route GET /api/v0/content/{ulid}/invocations/{id} (ricochet-rs/ricochet#1539) needs both.
• No server release ships that route yet. The server records a run before returning its ID, so a 404 means the server predates the route, and the CLI says to update the server.
• ricochet task invoke now shows the invocation ID. Every released server answers {"id", "content_id"}, but the CLI read invocation_id and status, which the server never sends, so the table never showed the ID. The response is now typed and the test mocks match the real shape.

Validation

• just check (fmt, clippy -D warnings, docs-check), cargo test --all-features (278 passed) and prek run -a pass.
• New binary tests in tests/json_output_test.rs: --wait polls through pending to success, a failed run exits non-zero while stdout still parses as JSON (the issue's verification case), a 503 on the first check is retried, a wait that fails names the lost run, and invocation get writes JSON alone. tests/invoke_test.rs covers the 404 message.
• Ran the binary against a stub server: exit 0 on success and 1 on failure in table mode; a 7 second outage mid-wait was ridden out; a server that stalls every status check ended the wait after 46 seconds with the run ID in the error.
• Not run against a real Ricochet server, since no release contains the route.

Instructions-PR: ricochet-rs/agent-instructions#42

Closes #216

[greptile-apps]

Confidence Score: 4/5

[Medium risk] Adds task run polling and status tracking to the CLI.

The PR is not ready to merge because a stalled status request can block a waiting CI job far beyond the advertised retry window.

Findings

1.  Stalled checks extend the wait ▶
2.  Failed waits lose the run ID ▶

Fix with agent prompt

### Issue 1
src/task/invocation.rs:127
If a status request connects but stalls, it can take five minutes to time out. This loop can make five such attempts, so `task invoke --wait` may block a CI job for roughly 25 minutes before failing, rather than giving up after the documented ~30-second outage window. Bound the status requests or the overall retry window.

### Issue 2
src/item/invoke.rs:58
If polling fails after the task starts, `wait` returns an error before this branch prints the run. In machine-readable mode, stdout contains no invocation ID, making it harder for a caller to use `task invocation get` to inspect the run. Keep the ID available when following the run fails.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR adds task invoke --wait, a command to inspect one invocation, and a typed invocation response so detached runs display their ID.

• Waiting polls pending runs and retries selected transport and server errors.
• Finished runs are printed before unsuccessful outcomes produce a non-zero exit.
• The retry window is not bounded when requests stall, and a polling failure can leave the newly started run without a machine-readable ID.

_{Reviews (1) · Last reviewed commit: "feat(task): follow a task run to complet..."}