fix(test): stop asserting concurrency via a wall-clock threshold

[githubrobbi]

Summary

Two `uffs-content` tests inferred concurrency from
`elapsed < sequential_estimate * 3 / 4` against 100ms-per-operation
fixtures. That threshold is only meaningful relative to how fast the
test machine happens to be that run — on a loaded/throttled
GitHub-hosted Windows runner, `thread::sleep(100ms)` itself can take
several hundred milliseconds of wall-clock time, pushing both the
sequential and concurrent paths past any fixed absolute threshold.

Hit for real in release PR #564's merge-queue run: elapsed 889ms vs. a
600ms "fully sequential" estimate — worse than fully sequential, which
is only possible under uniform scheduling overhead, not an actual
concurrency regression. I independently re-verified the dispatch code:
`emit::read_and_emit_all_candidates` and
`workflow::enumerate_all_roots_concurrently` both still spawn one
thread per lease/root via `std::thread::scope`.

Fix

Replace the wall-clock-ratio assertion with direct proof: record every
operation's (start, end) `Instant` and assert at least two intervals
overlap. Two things overlapping in time is true or false independent
of how slow the machine is.

Test plan

• 15/15 consecutive local runs of both tests
• `cargo xwin test --no-run` — cross-compiles clean
• `just lint-tests` (pedantic + nursery) — clean
• `cargo fmt --check` — clean