embassy-sync: wake the next waiter when a FairSemaphore acquire is canceled - #6964

FairSemaphore hands out permits in FIFO order, so a task asking for more permits than are currently available parks at the head of the queue and holds back everyone behind it. That part is intended. The problem is what happens when that head waiter goes away without ever acquiring: if its acquire future is dropped, nothing wakes the waiters behind it, and they stay pending even though there are already enough permits to satisfy them. Anything that cancels an acquire runs into this, select or with_timeout around sema.acquire(n) being the obvious cases. The queue only starts moving again if some unrelated release happens to come along.

The cause is FairSemaphoreState::cancel at embassy-sync/src/semaphore.rs:429. It clears the canceled waiter's slot with set_waker(ticket, None) and stops there. Every other place that changes who is at the head of the queue wakes the new head: take does it after popping a satisfied waiter, release and set do it after adding permits. Cancel was the one path that skipped it. #2766 fixed the same shape of lost wakeup on the completion path in 2024, so this is the half that was left.

The fix is to wake the new head from cancel when the head slot has become empty. wake() already pops canceled entries off the front and wakes whoever is next, so it comes to three lines. Checking the head first keeps cancelling a waiter that was not at the head free of spurious wakes.

The regression test is cancel_wakes_next_waiter, next to the existing fairness test. It builds a semaphore with one permit, queues a waiter for two permits and then a waiter for one, drops the first, and asserts the second gets woken and then completes. It uses a counting waker from futures-test instead of threads or timers, so there is nothing timing or platform dependent in it.

Verification, on an aarch64 Mac with the pinned 1.97 toolchain. cargo test --manifest-path ./embassy-sync/Cargo.toml, the command .github/ci/test.sh runs for this crate, gives 108 passed and 0 failed, plus the trybuild ui test and 9 doctests. Reverting only the cancel change and keeping the test gives cancel_wakes_next_waiter ... FAILED with assertion left == right failed, left: 0, right: 1 on the wake count, so the test does pin the behaviour. rustfmt --check --skip-children --unstable-features --edition 2024 under nightly-2026-08-26 from rust-toolchain-nightly.toml reports no changes. cargo build --target thumbv7em-none-eabi and cargo build --target thumbv6m-none-eabi --features defmt both succeed, so the crate still cross compiles.