bash: a cancelled bash_job wait parks the job again instead of killing it

[jaredLunde]

Fixes serve audit defect #8 (wrong output, from #254/#258).

Problem

Aborting a bash_job wait killed the job being waited on. The same happened when a busy compact, switch_session, new_session or fork self-aborted the run.

resume_job takes the job out of the table to wait on it, and the cancelled attach then dropped it. Dropping a Job kills it. So a server the model had started with run_in_background, and been told "keeps running after your turn ends", died silently:

• no bash_jobs_stopped frame was sent;
• the next bash_job said "no job 1: it was already reported, was stopped, or never existed".

Fix

When attach is cancelled while holding a job that already has a number, it parks the job back in the table and returns "Wait cancelled; job N is still running." Only a call's own fresh command dies with the call, which keeps cmd & grandchildren of an aborted command from leaking. A re-parked yielded job is still stopped by end_turn as usual. ARCHITECTURE.md and the attach doc are updated.

Tests

• New crates/agent/tests/bash_jobs_serve_abort.rs: start a background job, wait on it with bash_job, then abort. The test checks:

  • the process is alive;
  • no bash_jobs_stopped frame was sent;
  • the tool result says the wait was cancelled;
  • a timeout_ms: 0 peek on the next prompt still finds job 1 running.

  It fails on main with Command cancelled.

• cargo fmt, clippy --all-targets -D warnings and dprint check are clean. The agent + agent-core nextest suites passed in full, 3908/3908, on the stacked serve-jobs fixes.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JimHGjsfk2Ktm5GxyZJKKk