You're essentially using knowledge of an ECDH shared secret to prove knowledge of the private key associated with your static public key, thus authenticating yourself to the server.
If you use the same public key to authenticate yourself both to server A and server B, then this would allow either server to impersonate you.
For example, you would log in to server A, and server A would provide your username to server B and request an ephemeral public key from server B. Server A would provide server B's ephemeral public key to the client, as if it had come from server A. The client now provides the ECDH secret as a cookie to server A, and then server A can impersonate you with server B.
Your approach requires the server to keep a copy of every ephemeral public key issued. This would not be necessary if you had provided a signature, which is the normal approach to proving knowledge of your private key. Such a signature would need to be bound to the server you're contacting, to prevent it being used elsewhere. It would ideally also be bound to a server challenge and an expiry date, to prevent a replay attack from anyone that does not know your private key but happens to be able to gain knowledge of one of the signatures.
You can avoid reinventing the wheel by using a TLS client certificate for registration and authentication.