fix(desktop,web): contain renderer memory growth and recover from renderer OOM crashes - #5148

💭 Looking at the diff for Effect service convention violations across these files. The main concern is in DesktopWindow.ts where there's a mutable local variable tracking renderer recovery timestamps inside the Effect.gen block — it's a closure over state during service construction, which is probably fine. The other changes in Sidebar.logic.ts and threadReducer appear to be straightforward constant updates. Now I need to verify how runFork and runPromise are being used at the boundaries. In DesktopWindow.ts, runFork is called inside an Electron event callback, which is a framework boundary where this kind of usage is acceptable. The code already had void runPromise(...) patterns before, so I should check the actual imports and usage to confirm everything aligns with Effect conventions. threadReducer.ts looks clean with its pure implementation and subpath namespace imports. Now I need to examine DesktopWindow.ts and how it's using runFork. Looking at the runFork context around that section of the code. I'm wondering where runFork and runPromise are coming from—they're likely provided by the Effect.runtime that gets passed in through make, so let me verify that. I'm checking that the code follows existing patterns—the mutable state for recovery timestamps mirrors what's already used elsewhere, the reducer is pure, and the new tests make sense given the behavior change. Everything looks consistent with the codebase conventions, though I need to remember the final response should be formatted as JSON.