fix(clickgui): cancel pending bind listeners and modifier timers

[c8dhjp4tyv-bit]

Canceling a bind after pressing a modifier leaves input listeners and its timeout alive. Restarting immediately lets the old timeout finish the new session. Successful input also leaves the unused keyboard or mouse waiter subscribed, and component destruction does not cancel these waits.

Add optional AbortSignal support to waitMatches. Give each bind session its own controller, cancel the losing waiter, and clear listeners, timers and modifier state on completion, cancellation or destruction. Guard asynchronous continuations with the session's signal.

Validation:

• cd src-theme && node --test tests/bind-lifecycle.test.mjs: eight tests pass; five fail on the original implementation. No new dependencies.
• Full Gradle build, Detekt, theme build and client game tests passed on a separate branch combining the three contributions.
• npm run check reports the same 21 existing errors in seven files on the base revision and this branch, with no additional diagnostics.

https://github.com/c8dhjp4tyv-bit/LiquidBounce/actions/runs/38117439329

[liquidbounce-support-bot]

Thanks for the contribution and for including tests that fail on the old implementation.

A couple of small things a reviewer will probably bring up:

• tests/bind-lifecycle.test.mjs isn't hooked into any package.json script or CI step, so as things stand it only runs when someone starts it by hand. It might be worth adding a test script, or saying in the PR whether the test is meant to stay in the repo.
• The test pulls the component's script out with a regex on <script lang="ts"> and swaps in the export let setting line as a plain string. Any formatting change in BindSetting.svelte will break it, so a short comment saying that would help whoever runs into it later.
• The deleteListener change (removing the map entry once it has no handlers left) goes a bit beyond the bind lifecycle fix. Calling it out in the description would make review easier.

No user-facing behaviour changes, so the docs shouldn't need updating. A maintainer will do the actual review.

---

🤖 Automated support reply — a human maintainer will review if this doesn't help.