feat: timeout-minutes on cascade-owned jobs

[joshua-temple]

Problem

Cascade-owned jobs — setup, finalize, preflight, and the promote/release orchestration steps — do not emit a timeout-minutes field. GHA's default is 360 minutes (6 hours).

A hung git push in a retry loop, a CLI binary download stalling, or a blocked API call can hold a runner for six hours before GHA cleans it up. For orchestration jobs that are meant to be fast (setup typically runs in under a minute), this is an unnecessarily wide blast radius.

Orchestration frameworks that own jobs should bound those jobs. The right default for cascade-owned jobs is well under 30 minutes.

What to add

Emit timeout-minutes on all cascade-owned jobs. A sensible constant default (e.g. 15 minutes) is appropriate to start; the field can be made manifest-configurable later without a schema change.

Cascade-owned jobs affected:

• setup (orchestrate workflow)
• finalize (orchestrate workflow)
• preflight (orchestrate workflow, where it exists)
• The promote/release dispatch and state-management jobs

Callback jobs (user-authored workflows) are out of scope — those are the callback author's responsibility.

jobs:
  setup:
    timeout-minutes: 15
    runs-on: ubuntu-latest
    # ...

Acceptance criteria

• Every cascade-owned job in the generated orchestrate, promote, and release workflows includes a timeout-minutes field.
• The default value is a documented constant (not magic); the value is reasonable for the expected runtime of each job class (setup/finalize ≤ 15 min is a safe starting point).
• Callback jobs.<id>.uses jobs do not have timeout-minutes added (user-owned).
• Golden/snapshot tests updated to include the new field.
• e2e scenario: a generated orchestrate workflow's setup job has timeout-minutes set; triggering a deliberate hang (e.g. sleep 9999 injected in a test) causes the job to fail after the configured timeout rather than running for 6 hours.