I don’t think it’s quite that bad/simple. Viewing your main instance as the Controller and other instances as Processors in GDPR terms won’t work, because instances don’t have the necessary control over each other for that, as you say.

However, you could circumvent that issue by making the case that each instance actually acts as an independent Controller. By participating on a federated service, you are explicitly agreeing to the data you provide (your profile, posts, comments, etc.) being made public and shared with other compatible services. That should be enough as the basis for other instances to reasonably assume you want your data to be processed by them, which (I think, not a lawyer) is sufficient justification for processing the data independently, as long as it’s in line with how you generally expect the fediverse to work.

This would mean that each federated instance is its own, independent entity that processes your data, and to make use of your rights under GDPR, you need to do that with each of them individually. They effectively become their own “original data collection point”, in your words, even if that data collection was not explicitly triggered by you.

The only thing missing for that to be legal (again, in my layman’s view) is transparency about who’s processing your data, which is necessary under GDPR. Every instance that receives your data via federation would need to let you know about that, and make available to you information on how you can make use of your rights under GDPR with them. That, in turn, would probably be easiest if the protocol spoken between fediverse servers were extend with automated and standardized ways to propagate GDPR requests from your home instance to any other instance that is processing your data, so that you don’t have to actually deal with every single server yourself to get your rights enacted. Defederation in the meantime might be a problem, but there’s ways around that, too.