feat(shell): add wait_background_job tool

[simonferquel-clanker]

🤖 Automated implementer agent — this comment was posted by the implementer bot from Docker Agentic Platform, not by a human developer

Adds a wait_background_job tool to the shell toolset that blocks until a background job finishes and returns its exit code and captured output.

Previously, agents had to poll view_background_job in a loop to know when a background job completed. The new tool blocks on a done chan struct{} closed by monitorJob, eliminating polling entirely. An optional timeout parameter (default 60 s) caps the wait; the job keeps running if the timeout fires and the tool returns the current output with a notice.

Key changes:

• done chan struct{} on backgroundJob, closed by monitorJob via a deferred close (LIFO: Unlock before close, so callers see fully written state)
• Extract renderBackgroundJob() helper; refactor ViewBackgroundJob to use it; fix pre-existing issue: stopped jobs no longer show Exit Code: 0
• WaitBackgroundJob handler with ReadOnlyHint: true; selects on job.done / timer.C / ctx.Done
• 7 tests: completed, failed-exit, already-completed, unknown-id, timeout, context-cancelled, stopped-then-wait
• Docs updated: six tools, wait_background_job parameters table

Closes #3462

[docker-agent]

Assessment: 🟢 APPROVE

The wait_background_job implementation is correct and well-structured. Key design points verified:

• Defer ordering is correct: defer close(job.done) is registered first, defer job.outputMu.Unlock() second — LIFO ensures the mutex is released before the channel is closed, so WaitBackgroundJob readers always see fully-committed state.
• Stopped-job path: monitorJob acquires the lock, detects statusStopped, returns early; both defers still fire in correct order. statusStopped is present in statusStrings so the map lookup in WaitBackgroundJob is always valid.
• No double-close risk: done is only closed inside monitorJob, which runs exactly once per job.
• Timeout path: renderBackgroundJob is safely callable while the job is running (uses outputMu.RLock).
• 7 tests cover: completed, failed-exit, already-completed, unknown-id, timeout, context-cancelled, and stopped-then-wait.

No bugs found in the changes introduced by this PR.