Is there a way to get more information about parallel hash / sort spills from XML query plan
You can use DMVs to see tempdb usage.
The underlying cause is that one or more threads, for one or more correlated values of CntyCd results in a hash build-side memory requirement that exceeds the amount available to that thread.
The nature of nested loops means the execution plan would have to contain an array of performance information (one per CntyCd) and this would not be practical for loops with a large number of input-side rows. In any case, the facility does not exist today. You could go some way to determining which value causes the spill by executing the query with the same plan forced for each CntyCd.
It is quite possible the hash would still spill even if you dedicated the entire server memory to the hash table for this query. I hope it goes without saying that would not be a very sensible ambition.
I would look to rewrite the query to eliminate the hash join without introducing sorts. I would need a statistics-only copy of the database tables in question and a full copy of the query text (truncated in the XML plan at the moment). It is usually possible to find an efficient nested loops replacement given indexing freedom, which would avoid the enormous memory grants and spills.
I cannot promise to provide a working solution even if the information is provided, however. My free time for community work is limited, and this is the sort of query tuning I usually charge several hundred dollars per hour for.