safe_outputs job timeout (15m) is hardcoded and not configurable via frontmatter

[dsyme]

Problem

The safe_outputs job in compiled .lock.yml workflows always has timeout-minutes: 15, regardless of the top-level timeout-minutes value in the workflow frontmatter.

// pkg/workflow/compiler_safe_outputs_job.go, buildSafeOutputsJobFromParts()
Job{
    TimeoutMinutes: 15,  // hardcoded; comment: "Slightly longer timeout for consolidated job with multiple steps"
    ...
}

The top-level timeout-minutes frontmatter only propagates to the agent job, not to framework jobs (safe_outputs, detection, activation).

Impact

Workflows that push to large monorepos (e.g. github/github) via create_pull_request or push_to_pull_request_branch safe outputs are hitting the 15-minute wall. In run 27273467064 for the ci-perf workflow:

• Checkout of github/github with sparse-checkout + --filter=blob:none --depth=20: ~2m34s
• Fetch additional refs (master + ~25 dsyme/ci-perf/* branches at depth=20): ~38s
• Process Safe Outputs (applying patches, creating/updating PRs): started at 12:36:11, killed at exactly 12:47:30 (~11m19s elapsed, hit 15m wall from job start)

The workflow has timeout-minutes: 120 in frontmatter but this only reaches the agent job (timeout-minutes: 120 at line 1131 of the compiled YAML). The safe_outputs job gets timeout-minutes: 15 (line 1864).

Request

Please add a frontmatter option to configure the safe_outputs job timeout, for example:

---
timeout-minutes: 120
safe-outputs:
  timeout-minutes: 30
---

Or alternatively, propagate the top-level timeout-minutes to all framework jobs (with the current 15m as the minimum/default).

Workaround

None currently — the safe_outputs job cannot be configured via frontmatter and post-compilation patching of the lock file defeats the point of gh-aw.

[dsyme]

To add concrete data on why this matters for monorepos: in the failed run that prompted this issue, safe_outputs had 15 messages to process sequentially — 4x push_to_pull_request_branch, 2x create_pull_request, 3x add_reviewer, 3x add_labels, 3x add_comment.

Each push_to_pull_request_branch against github/github requires:

1. git ls-remote to check the remote branch tip
2. git fetch origin <branch> (network call to fetch that specific PR branch)
3. Apply the bundle locally
4. A GraphQL createCommitOnBranch mutation to sign-push the commit

Each create_pull_request additionally requires a git fetch origin master + potential rebase before the signed push.

14/15 messages completed successfully. The step was killed mid-git rebase on message 15 — not due to any git inefficiency (no deepening/unshallowing occurred anywhere; every bundle application logged "Bundle prerequisites already reachable; no deepen required") — just because the cumulative network latency of ~6 git fetch round-trips to github/github plus ~6 GraphQL mutations plus label/comment API calls exceeded 15 minutes.

So the constraint is simply: O(N) sequential network calls to the target repo, where N scales with how many safe output operations the agent produces. For a monorepo workflow that runs hourly and may produce 10–15 outputs per run, 15 minutes is routinely insufficient.

[pelikhan]

You can prompt to use templatable_int to support GitHub expressions