Add workflow execution timeout configuration

[stranske]

Description

Workflow executions currently use fixed timeout values defined in the workflow YAML files. When workflows need different timeout durations for different contexts (development vs production, simple vs complex tasks), there's no flexible way to configure these dynamically.

Proposed Solution

Implement a timeout configuration system that allows workflows to specify timeout values through:

1. Repository variables for environment-specific defaults
2. Workflow input parameters for manual override
3. Label-based timeout hints (e.g., timeout:extended for complex operations)
4. Automatic timeout scaling based on historical execution times

Implementation Details

• Add timeout configuration parser to workflow scripts
• Create repository variables: WORKFLOW_TIMEOUT_DEFAULT, WORKFLOW_TIMEOUT_EXTENDED
• Implement label detection for timeout hints
• Add timeout metadata to workflow run outputs for monitoring
• Update workflow documentation with timeout configuration examples
• Add timeout warning system that alerts 5 minutes before expiration

Acceptance Criteria

• Workflows can read timeout values from repository variables
• Manual workflow runs accept timeout override parameter
• Label timeout:extended increases timeout by 2x
• Timeout warnings logged when 80% of time consumed
• Documentation updated with configuration guide
• Existing workflows continue with current timeouts by default

Priority

Low - Nice to have for flexibility but current fixed timeouts work adequately.

Additional Context

This would be particularly useful for:

• Long-running verification workflows
• Matrix builds with varying complexity
• Development vs production environments
• Workflows that process variable-sized inputs

Labels

enhancement, workflows, configuration, technical-debt

[github-actions]

🤖 Auto-pilot step 1: Starting issue formatting...

Adding agents:format label to trigger LangChain formatting.

[github-actions]

Branch codex/issue-785 created from main.

Option 1 (Invite) is enforced on issue events. PR creation is disabled by design so you are the PR author. Auto Pilot only engages on human-authored PRs.

Please open the PR as the author so Auto Pilot can work on it:

• Compare link: https://github.com/stranske/Workflows/compare/main...codex/issue-785?expand=1
• Suggested title: Auto Pilot bootstrap for #785
• Suggested body (copy/paste):

<!-- meta:issue:785 -->

@auto-pilot Your objective is to satisfy the **Acceptance Criteria** by completing each **Task** within the defined **Scope**.

## Keepalive Next Task

**This round you MUST:**
1. Implement actual code or test changes that advance at least one incomplete task toward acceptance.
2. Commit meaningful source code (.py, .yml, .js, etc.)—not just status/docs updates.
3. Mark a task checkbox complete ONLY after verifying the implementation works.
4. Focus on the FIRST unchecked task unless blocked, then move to the next.

**Guidelines:**
- Keep edits scoped to the current task rather than reshaping the entire PR.
- Use repository instructions, conventions, and tests to validate work.
- Prefer small, reviewable commits; leave clear notes when follow-up is required.
- Do NOT work on unrelated improvements until all PR tasks are complete.

**COVERAGE TASKS - SPECIAL RULES:**
If a task mentions "coverage" or a percentage target (e.g., "≥95%", "to 95%"), you MUST:
1. After adding tests, run TARGETED coverage verification to avoid timeouts:
   - For a specific script like `scripts/foo.py`, run:
     `pytest tests/scripts/test_foo.py --cov=scripts/foo --cov-report=term-missing -m "not slow"`
   - If no matching test file exists, run:
     `pytest tests/ --cov=scripts/foo --cov-report=term-missing -m "not slow" -x`
2. Find the specific script in the coverage output table
3. Verify the `Cover` column shows the target percentage or higher
4. Only mark the task complete if the actual coverage meets the target
5. If coverage is below target, add more tests until it meets the target

IMPORTANT: Always use `-m "not slow"` to skip slow integration tests that may timeout.
IMPORTANT: Use targeted `--cov=scripts/specific_module` instead of `--cov=scripts` for faster feedback.

A coverage task is NOT complete just because you added tests. It is complete ONLY when the coverage command output confirms the target is met.

**The Tasks and Acceptance Criteria are provided in the appendix below.** Work through them in order.

<!-- 
  DO NOT ADD TASK CONTENT BELOW THIS LINE
  
  Task content is dynamically injected from the PR body via the `appendix` input.
  This template file should only contain instructions, not PR-specific tasks.
  
  If you see task content in this file, it was incorrectly committed and should
  be removed. The guard script will flag this as an error.
-->

[github-actions]

🤖 Auto-pilot step 1: Analyzing issue for improvements...

Adding agents:optimize label to trigger analysis.

[github-actions]

🤖 Auto-pilot step 1: Applying optimization suggestions...

Adding agents:apply-suggestions label.

[github-actions]

🤖 Auto-pilot step 1: Issue prepared! Assigning to agent...

Adding agent:codex label. The capability check will run automatically.

⏳ Agent will create a PR shortly.

[github-actions]

🤖 Auto-pilot step 1: PR created!

✅ Created PR #787 from branch codex/issue-785
✅ Added labels: agent:codex, agents:keepalive, autofix

The PR will now go through CI checks. Auto-pilot will continue monitoring.