feat(workflows): make shell step timeout configurable (#3327)

[Noor-ul-ain001]

Summary

Closes #3327. The workflow shell step hardcoded a 300-second subprocess timeout with no way to override it, so any command that legitimately runs longer than five minutes — a full build, a MegaLinter/golangci-lint aggregator, an integration-test target — was killed with TimeoutExpired and failed the entire run. There was no YAML knob to raise the limit, which made shell steps unusable as a probe/gate over real project QA commands.

Changes

• Add an optional timeout field (seconds) to the shell step, read via config.get("timeout", 300) and threaded into subprocess.run. Defaults to 300 so existing workflows are unaffected.
• The timeout failure message now reports the configured value instead of a hardcoded 300.
• validate rejects a timeout that is not a positive number. bool is rejected explicitly — it is an int subclass, but timeout: true is a config error, not a duration.

- id: qa
  type: shell
  timeout: 1800        # seconds; optional, default 300
  run: make code-qa

Acceptance criteria (from the issue)

• A timeout: value overrides the 300s default and is honored by subprocess.run.
• Omitting timeout: preserves current behavior (300s).
• validate rejects a non-positive or non-numeric timeout.
• A test asserts the configured value is threaded through.

Testing

Seven new tests under TestShellStep:

• configured timeout is passed to subprocess.run
• default 300 preserved when omitted
• timeout error message reflects the configured value
• validate rejects non-positive (0, -30) and non-numeric ("30", True) values
• validate accepts positive int/float

pytest tests/test_workflows.py::TestShellStep → 13 passed. Confirmed the behavior-changing tests fail without the source change (test-the-test via git stash).

🤖 Generated with Claude Code