feat: configurable default timeoutMs for workflow execution

[danielnc]

Problem

When OpenClaw's lobster tool runs a workflow, the subprocess timeout defaults to 20 seconds. This is too short for real-world Lobster workflows that perform multiple API calls in parallel (e.g., 8 parallel REST API calls + calendar lookups + file I/O = 15-30s typical).

This causes intermittent lobster subprocess timed out errors. The only workaround today is for every caller to explicitly pass timeoutMs on each tool invocation — which is tedious and error-prone at scale (15+ cron jobs across multiple agents).

Proposed solution

Allow workflows to declare their own timeout expectation, either:

Option A: Workflow-level timeoutMs (preferred)

name: my-gather-workflow
timeoutMs: 120000  # workflow declares how long it needs
steps:
  - id: gather
    timeoutMs: 300000  # step-level timeout (already exists)
    command: |
      ...

OpenClaw's lobster tool would read this and use it as the subprocess timeout instead of the 20s default. The workflow author knows best how long their pipeline takes.

Option B: Global default in Lobster config

A CLI flag or env var like LOBSTER_DEFAULT_TIMEOUT_MS=120000 that raises the floor for all workflows.

Option C: OpenClaw config (less ideal)

tools:
  lobster:
    defaultTimeoutMs: 120000

This works but puts the burden on the OpenClaw operator rather than the workflow author.

Context

• Current default: 20,000ms (hardcoded in OpenClaw's lobster tool integration)
• Typical workflow duration: 15-40s (parallel API calls + file I/O)
• Affected: any workflow with non-trivial shell commands
• The step-level timeoutMs already exists but controls Lobster's internal command timeout, not the OpenClaw tool wrapper timeout

Workaround

Every cron/agent that calls the lobster tool must explicitly pass timeoutMs: 120000. We just patched 15 cron jobs to do this — new workflows will keep hitting the same issue until there's a proper default.