[Fix] Tasks loop when terminal chat replies time out

[roomote-roomote]

​Opened on behalf of @mrubens. Follow up by mentioning @roomote-roomote or in the web UI.

What changed

• Give Roomote's generated OpenCode MCP connection a 600-second request timeout so the client does not abandon a relay that is still within the platform's timeout envelope.
• Treat three retryable terminal chat-delivery failures as terminal instead of five.
• Count OpenCode-level send_chat_reply failures for closeout and clarification calls, including transport timeouts that never return a structured MCP tool result.
• After the third failure, log the terminal delivery problem, stop counting later failure events, complete the task, and emit missingChatCloseout metadata so the platform-owned fallback delivery path can surface the final response.
• Recheck the persisted terminal-delivery marker before requesting that fallback, so a timed-out reply that succeeds late suppresses the fallback instead of posting a duplicate terminal response.

Why this change was made

A chat-backed task could finish its implementation but remain active indefinitely when its terminal send_chat_reply call timed out at the MCP client boundary. The closeout hook kept requesting another terminal reply because the existing delivery-failure accounting only ran after the MCP server returned a structured failure.

The fallback decision also has to account for a timed-out MCP request that finishes successfully after the harness records its failure. A successful late delivery clears the persisted terminal-failure marker; using only the harness's in-memory latch would still request a second platform fallback.

Root cause analysis

The delivery path is OpenCode -> local Roomote MCP server -> worker HTTP relay -> /api/mcp/slack/thread_reply -> Slack. The controller is not involved in this request path.

OpenCode applies a 30-second default timeout to MCP tool requests. Roomote's worker relay allows a platform API request to run for up to 120 seconds per attempt, and the API handler may also wait on thread serialization, Slack thread verification, Slack retries, and post-delivery bookkeeping. The generated Roomote MCP configuration did not override OpenCode's shorter timeout, so OpenCode could return MCP error -32001: Request timed out while the relay was still in flight.

That client-side timeout bypassed the safeguard added for ordinary delivery failures: recordFailedChatDeliveryResult only sees a result after handleSendChatReply returns. With no recorded terminal failure, the stop hook continued to see an unsatisfied closeout and prompted the model to retry. The harness reminder counter did not solve retries initiated inside the model turn, and its state can be reset by later messages.

The fix aligns the outer MCP timeout with the relay envelope and independently observes failed terminal reply tool events in the OpenCode harness. This ensures even transport-level failures consume the same persisted three-attempt budget. Fallback eligibility is then derived from that persisted state, which a successful late reply clears.

Impact

Slow chat delivery can now return its structured platform result instead of being cut off after 30 seconds. If delivery still fails three times, the task reaches a completed state, records one terminal warning, and hands the final response to the platform fallback rather than looping indefinitely. If an apparently timed-out reply succeeds before completion, Roomote recognizes that success and does not post a duplicate fallback.

[roomote-community]

No new code issues found. See task

• The fallback still posts after a timed-out reply succeeds late, duplicating the terminal response. harness.ts:4926

_{Reviewed 6fc6adb}