Background terminal completion after attempt_completion should surface as completion response

[hannesrudolph]

Summary

When a task has already called attempt_completion and a background terminal command later finishes, the system should surface that completion in a way that aligns with the completion flow instead of only reporting through terminal/command_output paths.

Desired behavior

• If a background terminal finishes after attempt_completion, the task/completion flow should surface an attempt_completion-style response or equivalent completion result.
• The task should not silently stay completed while the terminal finishes out-of-band.
• Keep the UX/model behavior coherent around late terminal completion after a task has declared itself complete.

Notes

Current behavior appears to release the terminal as a background terminal and report later output through terminal status / command_output mechanisms rather than through attempt_completion.

[roomote-v0]

I'd like to help with this issue, but I need some clarification to ensure I implement the right solution. Here's my understanding of the current behavior:

1. When a task calls attempt_completion, the user sees the completion result and can accept or provide feedback.
2. When the user accepts, emitTaskCompleted fires, and eventually Task.dispose() releases all terminals via TerminalRegistry.releaseTerminalsForTask(), setting their taskId to undefined (making them "background terminals").
3. Background terminal output is only surfaced through getEnvironmentDetails(), which runs during task iterations -- but since the task is complete, no more iterations happen.
4. The output only becomes visible when a new task starts and calls getEnvironmentDetails().

Could you clarify the following:

• What UX should the user see? When a background terminal finishes after completion, should the user see a notification/toast in VSCode? Should the chat panel show an update? Or should the completion result block itself be amended?
• Should this block completion acceptance? Should attempt_completion prevent the user from accepting completion while there are still running terminals associated with the task? (Similar to how preventCompletionWithOpenTodos works.)
• Or should it be post-completion? If the task is already accepted as complete and a terminal finishes later, should the system automatically resume the task or create a follow-up message in the conversation?
• Scope of "background terminal": Does this apply only to terminals that were started by the task (via execute_command) and are still running when attempt_completion is called? Or does it also include terminals that were already background terminals before the task started?

Please mention @roomote in a comment with your answers, and I'll proceed with a proposed implementation plan.