timeout-minutes only bounds the agentic_execution step, leaving setup steps (and the job) unbounded

[not-mksv]

Context

timeout-minutes in workflow frontmatter is (by design, per ADR-49495) forwarded only to
the generated agentic_execution step. That ADR explicitly calls out the risk it leaves
unaddressed:

Without an explicit step-level timeout-minutes, GitHub Actions inherits the job-level
or workflow-level timeout (up to 360 minutes)

That's exactly what happened to us: the built-in "Install ripgrep" step
(setup/sh/install_ripgrep.sh, apt-get update && apt-get install -y ripgrep) hung for
1h49m on a transient runner issue, and since neither that step nor the agent/detection
job has any timeout-minutes, nothing failed it until we canceled the run manually. Left
alone it could have run for up to 6 hours (GitHub's job default), and our
concurrency: { group: ..., cancel-in-progress: false } would have queued the next
scheduled run behind it.

Request

Add a way to bound the whole job, not just the agentic_execution step - e.g.:

• honor timeout-minutes as a job-level timeout on the generated agent/detection jobs
  (in addition to the step-level one), or
• a separate frontmatter field (e.g. job-timeout-minutes) for this, similar to how the
  safe_outputs job already gets its own configurable/default job-level timeout.