fix(dart_async): assert lower time bounds only for async timing tests (#139)

[DenisovAV]

Fixes the flaky dart_async timing failures tracked in #139 (previously #105, #123).

Root cause (investigated, per #139's ask)

The timing tests asserted a narrow wall-clock window around each async delay — e.g. sleep(ms: 200) required time > 200 && time < 300. The upper bound measures host/CI scheduling speed, not binding correctness:

• The binding is correct and fast. Locally the whole dart_async suite runs in ~9s with every test passing, including sleep.
• On a loaded CI runner the same suite can take ~200s of wall-clock. The async operations still complete correctly and in the right order, but the elapsed-time upper bounds are exceeded.

So the failure is test design (narrow wall-clock assertions), not an async-runtime or generated-binding bug. sleep is simply the one that trips most often; across reruns it also jumps between the stable and 1.91 legs while nightly stays green — consistent with load, not a version issue.

Fix

For the delay-based tests, keep the lower bound (which proves the async plumbing actually suspended for the expected time) and drop the upper bound. This matches uniffi-rs's own futures fixture (test_futures.py), which asserts only assertGreater(elapsed, expected) with no upper bound.

9 delay assertions change from > LOW && < HIGH to > LOW; a comment documents the rationale.

Scope

This touches only the delay tests that have a lower bound. The immediate-operation checks (always_ready < 200, void <= 10, sync/constructor < N) share the same latent wall-clock fragility but have no lower bound to fall back on — leaving those for a separate decision rather than widening scope here.

Refs #139.

Update (review follow-up)

• concurrent_future was the one test where the upper bound (<= 300) was load-bearing — it distinguished concurrent (~200ms) from a regression that serializes Future.wait (~300ms). Rather than drop it to a lower bound only (which would let a serialized regression pass), it now measures the same two delays both concurrently and sequentially and asserts concurrent < sequential — a relative comparison that survives CI load where an absolute ceiling doesn't.
• Scope comment corrected: only the delay-based assertions became lower-bound-only; the immediate-operation checks (always_ready, void, sync methods, constructors) still assert an upper bound only and are a known, deliberately-deferred fragility.
• A small clippy commit (clippy::useless_borrows_in_formatting, -D warnings on the stable Lints job) is included so this branch's CI is green — it removes redundant & in five format!/println! args, unrelated to the timing change but sharing the same job.

[chavic]

Nice fix, thanks! This should un-red the other PRs too.

[DenisovAV]

Thanks for the approval @chavic! 🙏 Since this un-reds the Test Suite (stable/1.91) failures on #149 and #152 (they're the same dart_async timing flake), would you be able to merge it when you get a chance? That clears one of the two red checks currently blocking #149.