fix: prevent forged public keys from using valid attestations as proof to deceive users

[HashWarlock]

When a user wants to verify a log's signature using a public key, they first need to ensure that the public key was indeed generated within the TEE. This requires the user to verify the correctness of the remote attestation. However, users obtain the remote attestation by accessing the /verifiable/attestation endpoint, which calls the generateAttestation function. This function doesn't validate the agent ID and public key from the user's request, but instead directly generates a remote attestation. This doesn't prove that the public key corresponds to a private key generated within the TEE.
Assuming TLS communication is established between the user and Eliza, I propose two correct approaches:

The user provides the agent_id, subject, and publicKey required for private key generation to the generateAttestation function. Within this function, a key pair is generated using deriveKey, and the resulting public key is compared with the publicKey parameter. If they match, an attestation report should be generated with the publicKey included in the report.
Since Eliza has already stored the publicKey in the SQLite database during initial registerAgent, if we can ensure that the SQLite database content is encrypted and cannot be tampered with by software outside the TEE, the generateAttestation function can directly read the publicKey from the database using the agent_id, subject, and keypath. It then compares this with the publicKey in the user's request, and if they match, generates an attestation report.

In the current implementation, if someone sends a log to a user with a signature generated by a private key from outside the TEE, and provides this forged public key to the user, when the user requests an attestation through the /verifiable/attestation endpoint with the agent_id and corresponding public key, Eliza running in the TEE will directly send a valid attestation to the user. This allows users to be deceived

Originally posted by @lightning-li in #1369 (comment)