Is your feature request related to a problem? Please describe.
OpenClaw currently has only a single per-model timeoutSeconds (total timeout). This can abort a response even after streaming output has already started, which looks like the agent “hangs” mid-reply. There is no way to distinguish “no output at all” (TTFT issue) from “slow but ongoing output,” and no stall/idle detection when streaming stops mid-run.

Describe the solution you’d like
Introduce two optional timeout fields under agents.defaults, forming three timeout categories:

agents:
defaults:
timeoutSeconds: 180 # total timeout (existing)
firstTokenTimeoutSeconds: 60 # NEW: max time to first token
stallTimeoutSeconds: 30 # NEW: max idle gap during streaming

Behavior:

• Total timeout remains the absolute safety cap.
• First-token timeout starts when the call begins and clears on the first assistant output / streamed chunk.
• Stall timeout starts after first token and resets on every streamed chunk; triggers if idle gap exceeds N seconds.
• If new keys are not set, behavior stays exactly the same (fully backward compatible).

Describe alternatives you’ve considered

• Only increase timeoutSeconds: reduces false timeouts but still kills long-running streams.
• Only decrease timeoutSeconds: faster fallback but increases false timeouts for slow models.

Additional context / Evidence
Example logs (2026-02-17) — model names normalized to openai naming per request:
2026-02-17T15:46:35.295Z [agent/embedded] embedded run timeout ... timeoutMs=60000
2026-02-17T15:46:35.315Z [diagnostic] lane task error ... FailoverError: LLM request timed out.
2026-02-17T15:48:35.468Z Embedded agent failed before reply: All models failed (3): anthropic/claude-opus-4.6: LLM request timed out. | openai/gpt-5.2: LLM request timed out. | openai/gpt-5: LLM request timed out.