Add timeout-minutes to jobs that have none (PM_GH_REPO_024)

[anish-sujanani]

Add timeout-minutes to jobs that have none

Addresses PM_GH_REPO_024 — Workflow jobs must declare a timeout.

A job with no timeout-minutes inherits GitHub's default of 360 minutes, so a hung job
holds a runner for six hours before the platform stops it. This bounds 1 job;
worst case for this repo drops from 360 runner-minutes to 10.

Proposed values

Workflow	Job	Successful runs sampled	p50	p90	max	timeout-minutes
postman.yaml	postman	6	0.7m	0.8m	1.0m	10

How these were calculated

timeout-minutes = min(350, max(3, ceil(m x slowest SUCCESSFUL run)))
    m = 2.0 under 30m   1.5 for 30-120m   1.3 above 120m

• Source: GET /repos/{owner}/{repo}/actions/runs/{id}/jobs, per-job started_at to
  completed_at over the 50 most recent completed runs of each workflow. That is the same
  clock timeout-minutes uses: it starts when the job begins executing and excludes queue
  and runner-acquisition time, so it will read lower than the run duration shown in the
  Actions tab.
• Only successful runs were counted. Cancelled and failed runs measure when someone hit
  cancel or when a job died, not how long the work takes.
• Floor of 5 rather than 3 for any job that installs dependencies or runs a build or test
  suite. A 3-minute floor killed a legitimate job in CI earlier in this rollout.
• 350 cap because GitHub-hosted runners hard-stop at 360, so anything above it is decorative.

Verification

• The parsed YAML is identical before and after with timeout-minutes stripped from both
  trees, so nothing else moved.
• The diff adds only timeout-minutes: lines and deletes nothing.
• actionlint reports the same findings before and after.
• Re-running the tool refuses every job, so the change is idempotent.

Break risk

A timeout can only stop a job that exceeds it. If any value is tighter than you want, say so
and I will raise it — a loose bound still fixes the finding.