Check queue readiness and capacity before waiting

[cf-rhett]

Summary

Two guards on the async wait paths, one commit each.

The first attempts framed and stream queue operations before entering the async notifier. When the queue is not ready, the methods retain the existing notifier path, including its subscribe-before-recheck ordering. This avoids waker registration and notifier bookkeeping when a grant or frame is already available. A counting notifier test covers every async wait method without relying on timing.

The second handles the case the first cannot: a request larger than the buffer itself. FramedProducer::wait_grant and StreamProducer::wait_grant_exact documented that as "will never return" and parked forever on a size no amount of consumer progress can satisfy. Both now compare against capacity up front and return WriteGrantError::InsufficientSize, which is what the synchronous grant and grant_exact already answer for the same input rather than a second convention for the same condition. Capacity is fixed for the life of the queue, so the comparison happens once, before the wait. wait_grant_max_remaining is unaffected; it caps its ask at what is available.

That second commit changes wait_grant and wait_grant_exact to return Result, so it is an API break. Happy to split it back out if you would rather take the readiness check on its own.

#133 touches this same file, but the only overlap is that both append a test module at the end of framed.rs — whichever lands second needs a keep-both resolution, not a semantic one.

Testing

• cargo test --features=std
• cargo build --no-default-features
• cargo build --features=std
• cargo build --no-default-features --target=thumbv6m-none-eabi
• cargo build --target=thumbv6m-none-eabi --features=portable-atomic-unsafe-assume-single-core
• ./miri.sh
• cargo clippy --features=std --all-targets -- -D warnings

[titaniumtraveler]

Opportunistically trying to get the grant seems like a good idea, ye.

I kinda wonder why that wasn't the case before/why maitake doesn't do that by itself.

This section in maitake-sync::WaitCell might have something to do with it, but I would have to research the topic a bit more in-depth before being sure on this.

In particular, this function correctly registers interest in the [WaitCell]
prior to polling the function, ensuring that there is not a chance of a race
where the condition occurs AFTER checking but BEFORE registering interest
in the [WaitCell], which could lead to deadlock.

(In particular whether this case is relevant for BBQueue's polling behavior)