Thank you @dylan!
However with mild embarrassment I have to admit I think I’ve finally resolved my issue on my own. Though maybe something changed on your end, salvaging my pride 
Despite many changes around the DNS servers used by my system, I only did testing with the pi-hole instance installed on the system disabled once, and I hadn’t noticed any change in behavior. Ultimately, after fully removing pi-hole and restarting the system, my login to Tidal succeeded :0
I cannot possibly explain how Pi-Hole was blocking Roon, but the requests made by the NodeJS script succeeded (and in addition so did a Tidal client running in a VM). There appears to be different means of resolving DNS between Roon and other processes on the system like the Node runtime.
A nice diagnostic that could be run by Roon to assist in situations like this either could be:
- A check by Roon to see if the IP resolved for the Tidal API host is a known good Tidal server, low-visibility warning if not (probably impractical, requires a white list)
- An error that more specifically explains “there’s an HTTP server here but it’s not a valid Tidal API endpoint”. Note this is different than a misunderstood response error. Ideally this would make use of a simple request to the API, the response of which is unique & consistent enough to be used to “fingerprint” the host as a Tidal API server. If that request succeeds but doesn’t have the expected fingerprint we know with especially high certainty there’s a DNS issue.