You’re free to only respond there if you like, but it fundamentally makes no sense to argue that an issue with the behavior of TTN server software in a particular pattern of usage should be treated only on a vendor’s forum, and not on the TTN forum where there are people who actually understand the TTN server software.
Commanded downlink frequency is purely a behavior of the server, based on its current knowledge of gateway assignment (or maybe its cached knowledge of previous assignment) and possibly the ingress path by which reports arrive. All the gateway itself can do is refuse to transmit on a disallowed frequency; which is legally useful, but ultimately irrelevant to the functional problem of the server needing to command it to transmit on the correct frequency.
The gateway itself really has no role in this, only the registration (possibly registration history) and selected server do.
If I were to conceptually put that eui into another real (or simulated) gateway, point it at the same endpoint and uplink valid packets, I’d get the same invalid downlink responses. Whatever the pattern of usage that triggered this, it’s something that could be experienced by someone with any sort of a gateway, not just a RAK one.
(On a practical level, I strongly suspect that changing the gateway eui to a never before used value, registering it correctly, and pointing it at the correct endpoint is likely to work - at least if ttn-router-asia-se is supposed to support this bandplan?)