ThresholdWait has no documented cancel-safety contract

Problem

wait_for_*_threshold is the one method in this HAL that callers will realistically put inside a select! or a timeout combinator, which means its future will be dropped before completion in normal use. The trait documentation says nothing about what happens in that case.

Unanswered questions an implementer and a caller both need answered:

• If the alert latches (e.g. the ALERT pin asserts) and the future is then dropped, is the event lost or is it observed by the next call?
• Is it legal to drop the future mid-I2C-transaction, and if so what state is the sensor left in?
• Can two calls be made in sequence without re-arming thresholds?

This is the most important thing to specify about the trait and it is currently entirely unspecified.

Suggested fix

Add a # Cancel safety section to the generated ThresholdWait docs, following the convention used by embedded-hal-async and tokio. Decide and document whether implementations are required to be cancel-safe (preferred) or merely permitted not to be.

Locate the generated ThresholdWait trait documentation and review the cancel-safety conventions in embedded-hal-async and tokio. Determine the intended answers for dropped futures, interrupted I2C transactions, and consecutive calls, then add a Cancel safety section whose contract addresses each question.