fix: preserve tool_use_id when editing tool_result messages

[daniel-lxs]

Problem

When editing a user_feedback message that corresponds to a tool_result in the API conversation history, the previous behavior would delete the message and create a new one. This caused the tool_use_id to be lost, creating a mismatch between the tool_call and tool_result that caused errors with native tool protocols.

Solution

This PR implements in-place editing for tool_result messages:

Changes to Task.ts

• Added resumeAfterMessageEdit() method that properly resets task state and resumes the task loop without creating a new user message
• Clears pending ask states and promises
• Resets abort, streaming, and tool execution flags
• Updates environment details in the last user message
• Ensures the next API call includes full context

Changes to webviewMessageHandler.ts

• Detect when the edited message is a tool_result message in the API history
• Handle timestamp mismatch between clineMessages and apiConversationHistory using position-based matching
• Edit the tool_result content in place while preserving the tool_use_id
• Delete only messages after the edited one (not the edited message itself)
• Resume task loop using resumeAfterMessageEdit() instead of creating a new message

Testing

Manual testing confirmed that editing a tool result message now:

1. Preserves the original tool_use_id
2. Updates the content correctly
3. Resumes the task loop without API errors
4. Works with both text-only and image-containing edits

---

Important

Implements in-place editing for tool_result messages to preserve tool_use_id, ensuring task loop resumes correctly without creating new messages.

• Behavior:
  • Implements in-place editing for tool_result messages in Task.ts and webviewMessageHandler.ts to preserve tool_use_id.
  • resumeAfterMessageEdit() in Task.ts resets task state and resumes task loop without creating a new user message.
  • Handles timestamp mismatch and position-based matching for tool_result messages in webviewMessageHandler.ts.
• Task.ts:
  • Adds resumeAfterMessageEdit() to clear pending states, reset flags, update environment details, and ensure full context in next API call.
• webviewMessageHandler.ts:
  • Detects tool_result messages and edits content in place while preserving tool_use_id.
  • Deletes only messages after the edited one and resumes task loop using resumeAfterMessageEdit().
• Testing:
  • Manual testing confirms preservation of tool_use_id, correct content update, and task loop resumption without errors.

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

[roomote]

Rooviewer   See task on Roo Cloud

All previously flagged issues have been resolved. No new issues found.

• Remove empty debug if-block at lines 455-456
• Fix potential bug where multiple tool_result blocks would all be overwritten with identical content
• Add cleanup of orphaned condenseParent/truncationParent references when deleting subsequent messages

Previous reviews

• 58c1a5d: Review #1

_{Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues.}

[mrubens]

This all just feels really complicated... is it because of choices we made in how we implemented message editing?