I am not sure why you would need that link. I don't have any. I could google for one - but so could you.
But I will clarify one thing. We have a 32-bit application. A 32-bit application can at most address 4GB of memory without any extra tricks.
Way back in the old days, SQL Server itself did apply such tricks. Up to SQL Server 2008, SQL Server used something known as AWE, Address Window Extensions. This permitted 32-bit SQL Server to address a lot more than 4GB of memory for its buffer cache. The support for AWE was dropped when 64-bit server operating systems became the norm, and these days there is not even a 32-bit version of SQL Server.
SSMS does not use something like AWE, so to be able to cope with volumes beyond 4GB, it needs to do something else. I don't know for sure, but I assume that this temp file serves this purpose. That is, rather having all that 9GB of data in memory at once, it sends the data to a file, and as you scroll through the result set, it will read from that file.
Now you may ask: why is SSMS a 32-bit application? Shouldn't it be a 64-bit application? It absolutely should, but SSMS is based on the Visual Studio shell, and the Visual Studio team appears to have no plans to go 64-bit. Which probably makes sense for Visual Studio itself. But certainly not for SSMS.
You could try Azure Data Studio instead (which you get included when you install the most recent version of SSMS.) I am not particularly thrilled over ADS myself, but at least it is a 64-bit application.