fix: defer confirmation handling to resolve Windows event loop race condition

[tgbender]

When confirm_ask requests input, it reuses the underlying io.input_task. Since Coder.input_task is also awaiting io.input_task, both tasks wake up when the user types a response.

1. confirm_ask receives the input. If it's invalid (e.g., "what?"), it rejects it and loops, asking again.
2. Coder.input_task also receives the input. Because confirm_ask rejected it, the confirmation_acknowledgement flag is not set.
3. Consequently, Coder.input_task treats the invalid confirmation response as a new chat message (user_message), triggering a new discussion workflow with the LLM.

[tgbender]

So I've now ran into this command interception issue on macos as well. It'll prompt for the add file y/n/s and sometimes hitting that will send a "n" and trigger another exchange with the llm. I think this'll fix it (at least it appears to on my device) but worth getting another set of eyes on it.

[dwash96]

This probably also addresses #260, good looking out, merging into 0.90.0