For the love of God, do not use MediatR. Especially in scenarios Channels are designed for. It is mentally confusing and bloated abstraction, in most places simply resulting in more code achieving the same result at 0.25x(best case) speed.
This one, that is the problem. It makes it impossible to logically follow (without reviewing all type references) the flow of execution - just call a service directly instead of inventing 3 contexts and 2 intermediate message handlers that end up just passing the data to one consumer at the end.
The fact that this does not raise eyebrows is one of the (avoidable) reasons, among many, why C# gets bad rep. Go solves this by the virtue of its design that makes it painful to invent big brain solutions that should have stayed simple. This is where C# has much longer learning curve and requires judgement when applying the tools at hand.
I've been mostly using C# for GUI applications and recently have been thinking about relying on a message bus as the main communication device between services and view models. As you mentions that complicates the flow of logic and ones loses benefits of explicitly listing your dependencies you get by just injecting all your services via constructor parameters. But that makes it simpler to refactor complex view models and services without impacting the rest of the codebase (at least in theory, it's of course often messier in practice...).
Oh yeah, GUI applications impose completely different requirements and use messaging very often, the comment above was specifically addressed at a popular anti-pattern in back-end services.
Community Toolkit code is well written and often exists as "does not quite meet the bar for including in standard library but otherwise solves common use cases".
[0]: https://github.com/jbogard/MediatR