Given your explanation that nothing has changed for months and it suddenly stopped working, and with just the information you’ve provided so far, it’s nearly impossible to guess what could be wrong. 
Generally speaking though, it’s not a good idea to have a dCS component sitting on the other side of a wireless network (mesh or otherwise). The problem is not one of raw throughput (“900 Mbps” in your stated case), WiFi6 (or 7) has more than adequate throughput, the real issue is the significant packet jitter involved in the air-interface (note: completely different from the traditional synchronous interface jitter associated with HiFi), and usually results in unreliable operational experience in any kind of streaming.
If I’m not mistaken, dCS (and even Roon) will reject any support request where their components are sitting on the other end of a WiFi link.
That said, I do have a couple of additional comments - apologies for the length of this post, please feel free to stop reading if it’s TL;DR 
There are broadly 2 categories of problems when it comes to HiFi networking;
-
Device discovery issues - the usual “Mosaic can’t find my Rossini”… “UPnP Server disappears from Mosaic”… “Roon remote can’t find Roon Server”… etc. etc.
-
Streaming services quality issues - like, “Tracks keep skipping during Tidal playback”… “my Desktop Qobuz App works perfectly but Qobuz on dCS is intermittent”… etc.
First thing to note is that comparing one networking application that works, to another that doesn’t work, usually isn’t very helpful because in networking, different things typically work differently even if the end outcome is similar. For example, just because the Qobuz Desktop App works perfectly, doesn’t mean that Qobuz on a dCS component will; the two work differently, including (and especially) the Servers on the Internet that they access! (Yes, might be hard to understand or believe, but it’s true).
Secondly, to point 1. above, the mechanics of how each application discovers the dCS component is quite different - Mosaic discovering dCS, Roon discovering dCS, Tidal App (Direct) to dCS, Spotify App (Direct) to dCS, UPnP Server discovery by dCS, etc., they almost all work differently!
When it comes to device discovery, in most cases, Multicast is a key aspect of how devices are actually discovered. Even among professional networking practitioners, Multicast can be a bit of a “black art” because there are so many dependencies that could impact it working properly, including specific timers and timeouts (which is why there’s often a change in behaviour “after some time”).
Not only that, depending on the application involved, the Multicast specifics applied for the discovery can be quite different for different applications! For example, the way that Tidal Direct discovers a dCS component on the home network is based on mDNS (formerly “Bonjour”), which is totally different from how the dCS component discovers a UPnP Server on the home network, which is based on SSDP; the mechanics of the two couldn’t be more different. This is also why WiFi mesh systems are less than ideal, because some don’t handle Multicast properly or can be intermittent in its Multicast support.
With respect to 2. above, most people imagine that the Internet is static, when in fact the Internet is changing all the time. In many cases due to outages, but also due to capacity upgrades etc.
Your dCS component’s streaming path across the Internet to a Qobuz server last week could very well be different than it is today! And there’s no guarantee that the route today is any better (or worse) than it was last week (here’s a link for a “birdseye view” of instantaneous outages on the Internet)
The default behaviour of most folks is to blame dCS, when in fact the probability that a bug has suddenly emerged in your dCS hardware/software is infinitely small compared to the probability that something has changed on the Internet that is affecting your Streaming service.