Wait for a cancelled HID read to actually end

[corgan2222]

Fixes #55.

What was wrong

CancelIo only requests cancellation and returns immediately. The driver could still complete the read afterwards, writing into buf and into overlapped — but overlapped is a local that dies with the return, and the caller reuses buf for the next read. The kernel therefore wrote into memory the Go runtime had already handed to something else.

That is heap corruption. It surfaces nowhere near the cause: seventeen crash reports since 1.9.4, most of them fatal error: selectgo: bad wakeup with a stack pointing at a select in the cooling poll loop that has nothing to do with HID at all.

A second defect in the same two lines: CancelIo cancels only what the calling thread issued, and a goroutine does not stay on one thread. It could cancel nothing and still report success.

The fix

CancelIoEx, then GetOverlappedResult with wait=true. The waiting is the point — it is what makes the operation over before the buffers go back. ERROR_OPERATION_ABORTED is the expected outcome of a cancelled read and is not reported.

Scope

Only reachable with the special-hardware option on, which is off by default. It went from rare to constant in 1.9.4, when the cooling source started polling once a second instead of reading on the measurement tick — the timeout path went from occasional to continuous.

On testing

There is no unit test. The failure needs a real HID device, a read that times out, and the allocator to reuse the buffer before the driver writes — a race that cannot be staged in a test without faking the whole overlapped I/O layer, at which point the test would only assert the shape of the code it was written from. build.ps1 -Check passes; the real verification is a machine with a Kraken running for a day without a crash report.