Add timeout-minutes to the build job in .github/workflows/issue-worm.yml #170

What

Add a timeout-minutes key to the build job in .github/workflows/issue-worm.yml.

The job currently has no timeout, so it inherits GitHub Actions' default of 360 minutes (6 hours).

Why

The workflow runs on every issue-worm label event and invokes an action that makes network calls (DeepSeek API) and performs a git push. A hung network call or a stalled push will occupy a runner for up to 6 hours before GitHub kills it. For a label-triggered workflow this is a real cost and availability risk — especially on self-hosted runners where a stuck job blocks the runner for other work.

This was raised as a non-blocking hardening item in the AI review of PR #169 (section 3, "CLI and API safety").

How

1. Open .github/workflows/issue-worm.yml.
2. Locate the build job (the job that runs the leonarduk/issue-worm action).
3. Add timeout-minutes: 30 as a sibling key of runs-on, permissions, if, and steps on that job.

Example shape (adjust to match the existing job block):

jobs:
  build:
    runs-on: <existing value>
    timeout-minutes: 30
    permissions:
      contents: read
    if: github.event.label.name == 'issue-worm'
    steps:
      # ... unchanged

Pick the value based on observed run duration: 30 minutes is the reviewer's suggestion and is generous for a single action invocation plus a push. If real runs are consistently under a few minutes, 15 is also defensible. Do not set it so low that a slow DeepSeek response or a large repo push gets killed mid-flight.

Files Affected

• .github/workflows/issue-worm.yml

Constraints

• Do not change any other key on the build job (runs-on, permissions, if, concurrency, env, steps).
• Do not change the workflow-level concurrency block or the run-name expression.
• Do not touch the github-token: ${{ secrets.WORM_PAT }} input or the DEEPSEEK_API_KEY env wiring — those are separate follow-ups.
• Do not change the action ref (@v1) — pinning to a SHA is a separate follow-up.
• The workflow must still trigger on issues: labeled with the issue-worm label and must still be gated by if: github.event.label.name == 'issue-worm'.
• Out of scope: adding actionlint CI, gating DEEPSEEK_API_KEY, pinning the action SHA, documenting the run-name prefix contract.

LLM tier

Haiku — this is a single-key addition to one job block in one YAML file, with no design judgment required.

Success looks like

• .github/workflows/issue-worm.yml contains timeout-minutes: 30 (or another justified value) directly under the build job key.
• The YAML still parses and the workflow still triggers on the issue-worm label.
• A run that exceeds the timeout is cancelled by GitHub rather than occupying the runner for 6 hours.
• No other lines in the file are modified.

Failure looks like

• timeout-minutes is added at the workflow level (top-level timeout-minutes is not a valid key) instead of on the build job.
• The value is placed under a steps entry rather than the job.
• The if gate, concurrency block, permissions, or env block is altered as a side effect.
• The timeout is set so low that normal runs are killed before the action completes.
• The YAML becomes invalid (e.g. wrong indentation) and the workflow fails to load.

Follow-up from AI review of PR #169.