[APP-397] feat: unify watch clients

[briangregoryholmes]

Builds on #8504 and #8026 to unify the WatchFilesClient, WatchResourcesClient and WatchRequestClient into a single FileAndResourceWatcher.

• Adds optional auto close and reconnection behavior to SSEFetchClient

Checklist:

• Covered by tests
• Ran it and it works as intended
• Reviewed the diff before requesting a review
• Checked for unhandled edge cases
• Linked the issues it closes
• Checked if the docs need to be updated. If so, create a separate Linear DOCS issue
• Intend to cherry-pick into the release branch
• I'm proud of this work!

[ericpgreen2]

Nice work on this! The unified SSE endpoint is a solid approach for the connection limit issue, and the code is well-documented.

One area to flag: the SSEFetchClient changes and how they interact with the Conversation streaming use case.

Design consideration: SSEFetchClient now has two modes: simple streaming (Conversation) vs managed connection with heartbeat/reconnect/auto-close (file/resource watching). These use cases have pretty different needs:

	FileAndResourceWatcher	Conversation
Pattern	Persistent observer	Request/response
Lifetime	Long (hours)	Short (seconds)
Reconnect safe?	Yes (stateless)	No (could duplicate messages)
Auto-close needed?	Yes (connection limits)	No (ends naturally)

The params approach works, but it makes the class fairly modal. It is worth considering whether the connection management logic (heartbeat, auto-close, reconnect) should live in a wrapper instead, keeping SSEFetchClient as a simple streaming primitive. Not a blocker, just thinking about maintainability.

Minor items:

1. close event behavior changed - It previously fired in a finally block (always), but now only fires on AbortError. I checked and the Conversation handler is a no-op, so nothing will break. However, for correct SSE semantics, it is probably good to fire close whenever the stream ends, regardless of how it ends. Moving it back to a finally block would restore that behavior.

2. The backend's event: error is not explicitly handled in setupSSEEventHandlers() - it falls through to default and logs a warning.

Happy to chat through any of this!

---

Developed in collaboration with Claude Code

[briangregoryholmes]

@ericpgreen2 Reworked as a wrapper.

[ericpgreen2]

@ericpgreen2 Reworked as a wrapper.

Looks good! Let me know when ready for final review.

[ericpgreen2]

Looks great!