[Feature]: Enable the stall watchdog by default (stall_timeout_secs)

[JordanTheJet]

Summary

Give stall_timeout_secs a conservative non-zero default so a stalled turn aborts and retries instead of hanging indefinitely.

Problem statement

stall_timeout_secs documents 0 = disabled, and 0 is the default — so the stall watchdog ships off.

A turn that stops making progress (provider stops streaming, upstream connection wedges) hangs with no abort and no retry. The operator's only signal is a bot that never replies, which is indistinguishable from a dozen other failure modes. The recovery mechanism already exists and is simply not enabled.

Proposed solution

Default stall_timeout_secs to a conservative non-zero value. 300 is a starting suggestion; the specific value is a maintainer call. 0 remains available to disable the watchdog explicitly.

Suggested sequencing:

1. Agree a default generous enough not to abort legitimately slow turns.
2. Change the default; document it and note it in the changelog.
3. Add a regression test covering the abort-and-retry path at the default.

Non-goals / out of scope

• No change to retry counts or backoff strategy.
• No new watchdog behaviour — this only enables what already exists.
• No change to approval_timeout_secs or other channel timeouts.

Alternatives considered

• Keep 0 and document the recommendation. Leaves every install one wedged connection away from a silent hang, and the failure is hard to attribute.
• Enable only for specific channels. Arbitrary: the failure mode is transport-independent.
• Derive it from an existing timeout. Couples two unrelated tunables and makes the effective value harder to reason about.

Acceptance criteria

• Default is non-zero and documented.
• A stalled turn aborts and retries within the window.
• 0 still disables the watchdog.
• A regression test covers the abort path.

Architecture impact

channels/, docs/. No security surface: this changes failure recovery only, not what the agent may read, write, or execute.

Risk and rollback

Risk: a legitimately slow turn is aborted mid-flight if the default is too low — the main argument for a generous value rather than an aggressive one. Worth confirming during implementation whether abort-and-retry is safe for a turn that had already acted before stalling; that concern exists today for anyone who enabled the watchdog manually.

Rollback: set stall_timeout_secs = 0, restoring today's behaviour exactly.

Expected routing

Ordinary feature triage

Next decision surface

Ordinary triage is enough; the only genuinely open question is the specific value. Companion to #10166; the two are independent and can land separately.

Breaking change?

Yes

Data hygiene checks

• I removed personal/sensitive data from examples, payloads, and logs.
• I used neutral, project-focused wording and placeholders.

[Audacity88]

Suggested shape: enabling a conservative non-zero default makes sense, but the PR should be precise about the behavior it is actually changing. From the current wiring, stall_timeout_secs appears to protect the Discord gateway/listen loop by breaking out and reconnecting when no events arrive; if the implementation intends broader turn-level abort-and-retry behavior, it should prove that at the actual call sites rather than relying on the config-field description alone.

A default around 300 seconds seems like a reasonable starting point, with 0 remaining the explicit opt-out. The main regression coverage I would want is: the default starts the watchdog, a stall triggers the intended reconnect/recovery path, no watchdog starts when 0 is configured, and the recovery path does not duplicate or obscure a turn that may already have produced visible output or side effects.

That keeps the useful recovery behavior while making the scope and safety contract clear.