Summary

When ProcessingWatchdog fires, the error surfaced to users is:

⚠️ The LLM response stream stopped unexpectedly. Please try again. (ref: xxxxxxxx)

This is misleading — the stream didn't "stop unexpectedly." The watchdog timer expired and Netclaw actively cancelled it. Users and operators cannot distinguish between "the model crashed" and "the watchdog timed out after 120s of no streaming activity."

Current Behavior

The error message is constructed at LlmSessionActor.cs:2057-2060:

if (cause is TimeoutException)
    return _firstDeltaReceived
        ? "The LLM response stream stopped unexpectedly. Please try again."
        : "The LLM provider did not respond in time. The model may be overloaded or the context too large. Please try again.";

Neither branch mentions the actual timeout duration, the operation name, or the fact that this was a watchdog cancellation rather than a network failure.

Proposed Improvement

Include the timeout context in the error message:

• Stream idle timeout: "Response timed out: no streaming activity for 120s. Please try again."
• First token timeout: "The model did not respond within 600s. It may be overloaded or the context too large. Please try again."

The structured daemon log at line 887 already includes the operation name and ID — the user-facing message should carry similar context.

Additional Context

The subagent timeout path has a similar issue — SubAgentActor.cs:203-209 returns "Subagent timed out" which gets wrapped into a generic failure message. The user sees the same :warning: format with no indication that the underlying issue was a timeout vs. a crash.

Related: #717 (the timeout itself was caused by a bug, but the misleading error message made diagnosis harder)