Fix: Enhance prompt overwrites both edit and new message boxes

[roomote]

This PR attempts to address Issue #8553 where the "enhance prompt" feature incorrectly overwrites both the edit message box and the new message box when editing a message.

Problem

When a user is editing a message and uses the enhance prompt feature, the enhanced text appears in both:

1. The edit box (correct behavior)
2. The main new message box (incorrect behavior)

Solution

Added a context parameter to distinguish between different ChatTextArea instances:

• The backend now includes a context field in enhanced prompt response messages
• Each ChatTextArea instance sends its context ("main" or "edit") when requesting enhancement
• Each instance only responds to enhanced prompt messages matching its specific context

Changes

• Backend: Modified webviewMessageHandler.ts to include context from request in response
• Frontend: Updated ChatTextArea.tsx to send context and filter incoming messages
• Tests: Added comprehensive test coverage for the new context-aware behavior

Testing

• All existing tests pass
• Added new tests to verify context-specific behavior
• Manually tested the fix works as expected

Fixes #8553

Feedback and guidance are welcome!

---

Important

Fixes 'enhance prompt' feature to correctly target only the intended message box by using context parameters.

• Behavior:
  • Fixes issue where 'enhance prompt' overwrites both edit and new message boxes by adding a context parameter.
  • ChatTextArea instances now send their context ('main' or 'edit') when requesting enhancement.
  • Only responds to enhanced prompt messages matching its context.
• Backend:
  • Modified webviewMessageHandler.ts to include context in enhanced prompt responses.
• Frontend:
  • Updated ChatTextArea.tsx to send context and filter messages based on context.
• Tests:
  • Added tests in ChatTextArea.spec.tsx to verify context-specific behavior.
  • Tests ensure enhanced prompts are handled correctly for matching contexts and ignored for non-matching contexts.

^{This description was created by for 994e2a2. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

Self-review: reviewing my own code like a hall of mirrors for robots—still cheaper than therapy.

[roomote]

[P2] Backward-compatibility edge case: if older backends emit 'enhancedPrompt' without a context field, this instance will ignore the event and the spinner may never clear. Consider defaulting undefined context to 'main' so the main textarea still handles legacy messages.

Example:

const expectedContext = isEditMode ? "edit" : "main"
const incomingContext = message.context ?? "main"
if (incomingContext === expectedContext) {
  // ...
}

[roomote]

[P2] Missing error-path coverage: when an enhancedPrompt arrives with matching context but no text (error response), the component should still stop the loading spinner. Add a test asserting setIsEnhancingPrompt(false) is called (or the UI state reflects it) when message.text is undefined.

[roomote]

[P3] Performance: the message event listener re-subscribes on every inputValue change due to being in a useEffect with inputValue in deps. This can be avoided by using a ref for latest inputValue or the existing useEvent hook (already imported) so the handler stays stable while reading current state via refs, reducing listener churn.

[hannesrudolph]

Fix tested and works, did not review code