Origins host resources, but resources don’t always represent origins
The so-called “origin-based security model” as assumed here is provably false, as you have just demonstrated. The only way to reconcile this origin assumption with the actor model is if every origin has exactly 1 actor representing that origin, or if every agent gets their own origin. It is simply incorrect to assume that any actor resource on an origin is allowed to represent that entire origin (or that any key resource on that origin is allowed to represent that entire origin, which is even more incorrect).
This doesn’t have anything to do with JSON-LD, either – the fundamental error is in assigning a representative relationship between a key/actor and an origin simply by virtue of having an http(s) identifier within that origin’s authority. You must recognize that any resource being published on an origin might in fact have user-generated content. (If I am currently renting an apartment room, am I allowed to authorize things on my landlord’s behalf?)
JSON-LD isn’t relevant; any information needs to be trusted regardless
This doesn’t logically follow.
With regards to JSON-LD contexts, the processing of contexts only matters when you want to establish that we mean the same things when we use the same terms. For example, https://w3id.org/security/v1 defines the term CryptographicKey to be shorthand for https://w3id.org/security#Key. But for that same concept of a https://w3id.org/security#Key, you might call it a Key instead. The JSON-LD context definition allows us to recognize that what you call a Key and what I call a CryptographicKey are actually the same thing: a https://w3id.org/security#Key.
If we were to do away with JSON-LD contexts altogether, what you are effectively describing is a situation where user-generated content is not allowed to make statements as defined by the Security Vocabulary that a certain resource is a cryptographic key, or that a certain resource has public key material corresponding to some literal string, or so on – basically disallowing statements of the form ?s sec:publicKeyPem ?keymaterial. I don’t see why you would do this, since you should be allowed to assert such descriptive statements without it affecting anyone else except by whatever knowledge they import from you… and why should they trust arbitrary statements? (If we were to go further and do away with JSON-LD altogether, you would have to ban certain JSON property keys from being used as agreed upon by some central registry.)
How to solve the problem
Remote contexts shouldn’t pose an issue in the abstract sense, but I understand that JSON-LD contexts are currently mishandled in a variety of ways by a variety of current fediverse instance software.
With respect to the context changing, this can happen but generally should not. If it breaks your security assumptions, then your C2S server should disallow remote contexts… but there isn’t really justification for this idea, because as mentioned earlier, you can inline a context and then change the inlined context later, too. You could also not use any additional context at all. So the solution you’d want to pursue is not “drop JSON-LD”, but “disallow publishing statements using sec:publicKeyPem” (again, as brought up earlier). You’d need to check for these statements on any Create or Update, in theory.
Ultimately, the error is in the initial assumption that a key resource on an origin is authorized to represent that entire origin. Nothing good can come from that. This doesn’t fully “undo” the origin based security model, but it does mean you have to reconsider the incorrect parts of it. Like, really consider the assumptions you’re making here. How committed are you to the idea of “origins” as a security boundary? Would you expect everyone to have their own FQDN instead of allowing multi-tenancy? Do you want to disallow split storage models (where alice.social.example might have objects stored on cdn.social.example)? I’d go so far as to say that the primary value of the origin model is that it allows for authentication via TLS. If that doesn’t apply to your use case, then there isn’t much point to it.