> The value of x-client-data is personal data, because it is associated with an IP address during transit, due to how HTTP requests work.
This is not correct. The x-client-data is not personal data. x-client-data associated with an IP address is personal data. As soon as you separate the client-data from the IP, the client data stops being personal data. IOW, the tuple (x-client-data, IP) is personal data. But x-client-data on its own isn't personal data, because it cannot be used to infer the IP on its own.
I don't know where you're getting this "if two pieces of data ever touch and one of them is personal data the other one is now also contaminated as personal data". It's not true. That would make the existence of anonymous data (which the GDPR specifies as a thing) practically speaking impossible to have on the web, since all requests are associated with the IP on receipt. (or actually even worse, it would make the process of anonymizing data impossible in general, since the anonymization process associates the anonymized data with the original personal data).
To be precise, the GDPR defines anonymized data as "data rendered anonymous in such a way that the data subject is not or no longer identifiable.". The x-client-data header is exactly that. The subject of the header is not identifiable by the x-client-data header alone. Therefore the header is anonymous and not subject to strong GDPR reqs.
For the client data header to be personal data, you'd need to describe a scheme such that, given an x-client-data header, and only an x-client-data header, you could identify one (and only one) unique person to whom that header corresponds. You're welcome to come up with such a scheme, but my intro CS classes taught me that bucketed hashing is irreversible, and with 8192 buckets, you're not going to be able to uniquely identify anyone specific.