[Bare7a]

📝 What changed?

A cancel from an AI assistant was lost when it arrived before the call's query had registered, for example while the server was still reloading the saved connections. cancel_query found nothing to stop, so the query started anyway and ran to the end, holding its connection (SQLite's only one) the whole time. Now call() races the tool against the cancel with tokio::select!, so every tool except run_change stops the moment it's cancelled. A cancelled call still gets no answer.

• run_change keeps its own handling, which takes its approval question down or rolls the change back.
• A newer call that reuses the request id drops the older call's cancel sender, so wait_for returns Err. The Ok(_) pattern skips that, so the older call keeps running.

🧩 Type of change

• 🐛 Bug fix
• ✨ Feature
• ♻️ Refactor
• ⬆️ Dependencies
• 📝 Docs or landing page
• 🛠️ Build, CI or packaging

🧪 Tested

• By hand on Windows
• By hand on macOS
• By hand on Linux
• Tests workflow on macOS and Windows

📖 Docs

• Updated the guide
• Updated the README or landing page
• No docs needed

📌 Notes

This race made a_reused_request_id_leaves_the_newer_call_cancellable fail once in the Linux E2E job on #41 (run), where the cancel came before the endless query had registered. The new test a_cancel_before_the_query_registers_still_stops_it holds the engines lock so a call parks before its query registers. It then cancels the call and checks that it settles without an answer. Without the fix it fails with "the cancel was lost".