Leaving the JSON formatting aside, the question considers a server receiving public key $\mathrm{pk}$, an ECDSA signature $S$, and message $M$; and asks if the signature should be on $M$ or $\mathrm{pk}\|M$.
Contrary to standard practice, the server has no way to authenticate $\mathrm{pk}$; it only checks that $\mathrm{pk}$ is a valid ECDSA key, and that $\mathrm{pk}$ and $S$ verify against $M$ or $\mathrm{pk}\|M$, per ECDSA P-384.
The originally stated goal (in this comment) was:
I only want to ensure that the message itself hasn't been tampered with.
This goal is not and can't be met under the standard assumption in crypto when it comes to message tampering: an active malicious adversary. There's nothing to stop the message from being extracted, modified, resigned with a new private key $\mathrm{sk'}$, which matching new public key $\mathrm{pk'}$ replaces $\mathrm{pk}$.
The updated goal is:
I only want to ensure that the message itself hasn't been tampered with from the public key it's being sent by.
Reading this as "…hasn't been tampered with compared to when it was signed with the private key matching the public key it's received with", that goal is met with both signing methods (under the standard assumption that ECDSA P-384 is EUF-CMA secure):
Some other goals are met too (under further standard assumptions that whoever generates the $\mathrm{sk}/\mathrm{pk}$ key pair does so securely and does not let $\mathrm{sk}$ leak, and uses it only for the purpose of signing messages as prescribed):
- The server can be convinced that $\mathrm{pk}\mathbin\|S\mathbin\|M$ and $\mathrm{pk}\mathbin\|S'\mathbin\|M'$ that both verify are signed by the same signer, and that neither $M$ nor $M'$ are altered compared to what that signer signed.
- A party knowing $\mathrm{sk}$ matching $\mathrm{pk}$ can convince the server that it knew $M$ when the server received $\mathrm{pk}\mathbin\|S\mathbin\|M$ that verifies.
Towards the above goals (and under the standard assumption that the hash used in ECDSA is secure), I do not see a security advantage to the more complex option of signing $\mathrm{pk}\|M$.
If the public/private key pair $\mathrm{pk}/\mathrm{sk}$ is used for multiple purposes (against the "one use, one key" principle), and if the server's protocol is the only of these purposes such that $\mathrm{pk}$ could appear at start of what's signed, then signing $\mathrm{pk}\|M$ has the beneficial side effect that it's impossible to misuse a signature produced for another use towards impersonating the holder of the key pair on the server. However, the convention of signing $\mathrm{Prefix}\|M$ where $\mathrm{Prefix}$ is unique to each use is a cleaner way to achieve the same goal.
There are some other thin security advantages; like: advance knowledge of the hash of $M$ can't help an adversary misappropriate a message $M$ that it does not yet know in entirety. If only $M$ is signed, such attack is possible by altering the beginning of $\mathrm{pk}\mathbin\|S\mathbin\|M$.
Looking at the attacks in Dennis Jackson, Cas Cremers, Katriel Cohn-Gordon, and Ralf Sasse's Seems Legit: Automated Analysis of Subtle Attacks on Protocols that Use Signatures, I do not see that they would be a concern in the context, and further:
- ECDSA with fixed curve (as in the question) is secure against SEO/DEO attacks that misappropriate a signature (signing $\mathrm{pk}\|M$ thwarts that, including when the curve is a parameter of the public key).
- ECDSA signatures are malleable (ECDSA is not sEUF-CMA), but that's regardless of what's hashed.
Signing $\mathrm{pk}\|M$ has a functional disadvantage beside what the question lists: if the server de-duplicates large messages sent by multiple users, then the server has to hash the whole message once more for each signature verified.
