worker: a foreground call waits 600 s before it becomes a job — is that the right ceiling?

[AbirAbbas]

A fresh-install check on 2026-09-25 (dev-20260925-1194d4b8fe88, devaf installer, WSL) ran a default /task that took 22m37s for a one-line bug fix. About 10 of those minutes were one worker command, find / -name test_calc.py -not -path '*/proc/*', which walks /mnt/c on WSL. A foreground bash call runs for up to BashCeilingSeconds (600 s) before it becomes a background job, so the task sat silent for ten minutes before the worker got control back.

The question: is 600 s the right foreground ceiling for a worker, or should a worker's call hand off sooner, for example after 60–120 s, the way the chat's backgroundAfter path does?

Where

• BashCeilingSeconds (internal/exec/bare), and timeoutSentence in internal/session/tools_jobs.go, which interpolates it into the tool description.
• The job hand-off: BashPromotedLead in internal/session/promote.go.

Context

Since #1515, a worker can stop a job it started through jobs. Before that, the backgrounded find ran on for the rest of the task. A shorter hand-off is only useful now that the worker can act on it.