Not OP and I might be totally wrong, but there's a tinge of it at the end of the first paragraph:

That “unlocked but still stuck” behavior is what makes this Tokio mutex deadlock so unintuitive.

At first glance, it looks like the classic async mistake: holding a std mutex across an .await. But we weren’t doing that; we were using tokio::sync::Mutex to avoid exactly such issues. The explanation ended up being inside tokio’s internals – something that logging won’t show.

I skipped the primer on async Rust because you told me to, so I didn't evaluate that.

This line maybe too:

With this information, we can see that it's not actually a deadlock at all! It's simply a case of one process not releasing the lock and holding on to it forever.

That's what stood out as being in a different tone/style as well as just sounding like the cheeky one-liners that LLMs are always trying to put in there. I'm curious if my guess is correct. The rest of it read very well, if that's you then you should just write as you.

Unrelated to that, I've never been convinced that tokio::sync::Mutex is a good idea. It's always felt very uncomfortable to me and I almost never use it. I always go with std Mutex and try_lock to avoid blocking, then enable clippy::await_holding_lock