[BUG] Orchestrator - Queued messages during "attempt_completion" cause the completion to be automatically accepted instead of messages sent

[ApocDev]

Problem (one or two sentences)

If you have messages queued while a task is finishing, or near finishing, the attempt_completion is automatically accepted without actually sending the queued message. This causes issues in the orchestrator flow due to having to go back to the subtask, re-send the message ( and whatever other interactions are required ) then wait for a summary to be spit out again, copy/paste it back to orchestrator to let it know the "new" summary (which was tainted by the previous early submission)

It seems like the queued messages are also not being injected at the earliest place possible, but I will make a separate issue for that.

Context (who is affected and when)

All users.

Reproduction steps

1. Run an orchestrator based task
2. Queue up a message during the "summary" message stream

Expected result

The current task to see the queued message, and not automatically accept the completion

Actual result

Subtask is marked as completed, ignoring queued message

Variations tried (optional)

No response

App Version

3.32.1

API Provider (optional)

None

Model Used (optional)

No response

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote]

I'm exploring a potential fix for the queued messages issue during attempt_completion in orchestrator flows. I'll open a PR to share progress.

[roomote]

Opened PR #9316 with my attempt at addressing this issue. The fix prevents auto-acceptance of attempt_completion when messages are queued, instead processing them as user feedback. Feedback welcome!