Might fix #2704

I can't replicate that issue just yet so i have no idea

It could be a classic race condition. When the UI selects an entry, it only stores the index of the selected item, not the actual entry itself. Then later, when it comes time to actually return the command, it goes back to the results array and grabs whatever is at that index. This is fine most of the time...

BUT - if anything changed the results array between selection and execution (like a new search query being processed), the index would still point to the same position, but that position might now contain a completely different history entry! 🫠

There's another potential cause too. We have the main loop, that handles calling draw + also updating the results when needed. But an inner loop, that processes all input events received. If a user sends a lot of events (maybe holds the arrow key?), then there could be a discrepancy between the selected state and the currently rendered state. Ensure we also call draw when we process the Continue event.

Checks

• I am happy for maintainers to push small adjustments to this PR, to speed up the review cycle
• I have checked that there are no existing pull requests for the same thing