Sorry about response time here, familiy stuff happened.
Yes emails are PII. In general anything that can identify a person. Its a broad interpretation of "identify a person", and actually hasn't got anything to do with the sensitivity of the information. There are classes of PII for sensitive data, and extra rules for processing that, but when figuring out _if_ data is PII, sensitivity doesn't really come into it.
And you are correct, _any_ PII is "game over" in this case. But this case (US EU) is also a bit of an edge case to GDPR I think. I mean most of GDPR is concerned with how a company should handle PII. Then there are some rules about transferring data to "unsafe" countries. Unsafe in this case means countries where there is high risk that the company is not handling PII correctly and/or nothing the EU (citizen) can do about it. And this is where your CLOUD Act + Schrems II comes in. It makes US an "unsafe" country to transfer data to because it brings a high risk for the EU citizen that their GDPR rights cannot/will not be enforced (and the Privacy Shield agreenment that used to make it okay away is no longer valid).
Its unfortunate, I think, because it puts GDPR in a special negative light for US engineers, and that takes away from the many good things in GDPR. I actually think most of the stuff in there is pretty good. And just for reference - I run my own company, so I'm "enjoying" GDPR compliance fully, and sure, its more work, but I haven't yet encountered a part of GDPR where I havn't though "isn't this actually how I wanted my data to be handled by other companies?"
Okay, now for the fun part - thinking up designs/architectures where your product would be GDPR compliant. Im just doing this for my own fun btw, and perhaps a nice discussion. Not trying to tell you what to do :)
Since we have the hole "unsafe" third country situation, no transfer of PII is okay. This is a bit more restricted that what we would normally deal with under GDPR.
The basic tenants for being compliant here is two things: 1) If you/your employees hasn't got access to the data, e.g. because you don't have it, you are not handling PII. 2) If data is not being sent from the client (located in EU) to your US servers, you don't have the "unsafe" country data transfer situation. And the your are compliant.
Emails (and other data attributes, like username, name, CC details, shoe size etc). I think the way to go about this is thinking in terms of that you actually need server side to make core functionality work, and what could actually be kept client side and never sent to your servers. See, in this case the problem is transferring the PII to the US. If you can somehow have a "fat" application client side, like a SPA, could you avoid sending the email to the server? What you must have is a unique identifier for users, sure, and email is normally that. But you could hash the email addr and use that as a unique key for the user. You just need it to be guaranteed unique, and dont care (most likely) what the actual mail address is. Note: Stil have to be careful with the hashed email as unique key because that could still identify a user, since its unique, and therefore PII. However if you hash client side and only send the hash, you will only have the hash server side. And if the only datapoint you have is a hash then it cannot identify a person on its own (given the properties of a one-way hash function). You'd need to put that hash in context with other info to be able to identify a person from it. And then its not PII, and you can send it to your server no problem.
The same concept should be usable for most basic data attributes, i.e. shift everything PII to the client, and if data needs to be sent then do you actually the actual value of the data or do you just need the data to have a certain property, e.g. be unique or be not-null or whatever.
Then there is the matter of storing all this data we've now shifted to the client. This is were the textbook would say "left as exercise for the reader" LOL. Storage for web apps especially is gonna be annoying to deal with. If you have an actual (not web app) client, its much easier. If your users are developers, you can get away with less user-friendly ways of managing that data client side in a web app. It seems solvable without too much fuss, with some form of local storage.
Public keys. This one is though. A public key is PII. You need the public key server side because (I'm guessing) when a user submits code (s)he attaches a signature, that you need to verify. You having that public key is part of the hole PKI idea. The first idea that comes to mind is based on the same "do you need the value of the data or do you need to know a property about the data"-thinking. You need to know the signature is valid for the submitted code. If you had a magic black box that could give you a yes/no (that you could trust) on that, you wouldn't actually need the public key, you could just give the code and the signature to your black box and it would say yay or nay.
If there was a service (i.e. API) on a server in europe that played the part of the black box, and you trusted it, you could "just" call the service with the signature (again hashed/encrypted and if you don't have the key, you can't relate the signature to a person, so its not PII) and code as input, and the service would return true/false, when you would have what you need. And no PII i.e. the public key would need to be transferred to your server / you wound't need to handle (store) it. Here is the bad part about this idea: Schrems II is actually saying that its not enough for the server/service to be in EU. If the company running the server/service is US owned, its still considered a data transfer to a US entity. So the signature verification service in EU would have to be run by someone not you/your company. And you'd ofc need to pay to use that service, no free lunch. So you'll have to consider if the value of being able to offer your product to EU customers worth the hassle and cost of this setup?
I feel like there must be more solutions to the public key one, but they don't come to mind right now. Was a fun exercise anyway :) I'm sure I've made so many assumptions about how your product works, that the above suggestions would never work in practise, but my point was more to illustrate that GDPR compliance can be dealt with by rethinking many of our go-to design patterns (i.e. have a central database with user info).
Btw something like the above would be privacy by design, which is a core principle of GDPR and if one makes a product in that way, that would be way more compliant than 99% of all software that existed pre GPRD and slapped compliance on after GDPR was introduced.