fix: prevent responseListeners memory leak in CoreMessenger

[RomneyDa]

Summary

• Fixes a memory leak in CoreMessenger.responseListeners where callback entries were never removed for non-streaming messages
• Response listeners were only cleaned up when data contained "done": true, but most message types (files/changed, files/opened, autocomplete, nextEdit/*, etc.) return responses without a done field — leaking every callback permanently
• Over a long session with heavy autocomplete and file navigation, this can accumulate hundreds of thousands of entries (estimated 40-100+ MB)
• Fix: invert the removal logic — remove the listener by default, only retain it when done == false (streaming still in progress). This is safe for all message types:
  • Streaming responses (done: false → done: true): listener kept during streaming, removed on completion — same as before
  • Non-streaming responses (no done field): listener removed immediately after callback — this is the fix
  • Fire-and-forget ({ _ -> } / {}): listener removed on first response — this is the fix

Related: #8085 (sidebar freezes), which identified memory pressure as a contributing factor

Test plan

• Stream a long LLM response in the sidebar — verify it streams correctly and completes
• Navigate between files, open/close tabs — verify no regressions
• Use autocomplete heavily — verify suggestions still work
• Monitor JVM heap over a long session — confirm responseListeners map stays small

---

Summary by cubic

Fixes a memory leak in CoreMessenger by removing response listeners by default and only keeping them during streaming (done == false). This prevents responseListeners from growing unbounded during autocomplete and file events.

• Bug Fixes
  • Invert cleanup: remove listener when done != false; keep only while streaming.
  • Non-streaming responses (no done) and fire-and-forget calls now clean up after the first callback; streaming completion still removes on done: true.

^{Written for commit cf67e4d. Summary will update on new commits.}

[continue]

Docs Review

No documentation updates needed for this PR.

Reason: This is an internal bug fix that addresses a memory leak in the IntelliJ extension's CoreMessenger response listener cleanup logic. The change is purely an implementation detail that doesn't affect:

• User-facing behavior or features
• Configuration options or settings
• API contracts or extension points
• Installation or setup procedures

The fix improves memory management under the hood without changing how developers interact with Continue.

[cubic-dev-ai]

No issues found across 1 file