fix(ctx_shell): stop reporting a requested background cancel as a tool error

[andig]

Cancelling a background ctx_shell job answered with the same [background:<id> running] string that background_action: "status" returns, so the cancel was indistinguishable from a no-op poll — and the obvious follow-up (cancel again) surfaced the process's own SIGINT exit as the tool's exit code. In Claude Code that fires the PostToolUseFailure hook and instructs the agent to fix a non-problem.

Changes

• First cancel is acknowledged. A cancel on a running job now returns [background:<id> cancel requested — job is stopping; poll status for the final output] instead of the status wording.
• A completed cancel is not a tool error. The terminal state reports as [background:<id> cancelled]\n<output>\n[cancelled: <id>, exit 130] with exit 0, so exit 130 stays visible as data without tripping the failure hook.
• Cancel is idempotent. Cancelling an already-cancelled, already-finished (any exit code) or already-pruned job is equally non-error. A status poll keeps its previous exit-code semantics.
• ERROR: command cancelled in the captured output becomes [cancelled: command stopped on request] — the flag is only ever set by an explicit cancel, so the ERROR: prefix was wrong at the source too.

The formatting moved into format_background_state(id, is_cancel, state); no tool-schema or description change.

Testing

• New tools::registered::ctx_shell::tests::cancel_is_acknowledged_and_never_reports_a_failure covers the ack wording, exit 0 on the cancelled state, idempotence over Completed/None, and that a status poll is unaffected.
• cargo test --lib ctx_shell:: (58 passed), cargo test --lib background_shell:: (9 passed), cargo clippy --all-targets clean.

Fixes #1246

🤖 Generated with Claude Code