security: sign AttestationReport critical fields

[createkr]

Summary

This change adds authenticity protection to AttestationReport so critical fields cannot be modified or replayed without detection.

What changed

• Added Ed25519 signing support in rustchain-miner
• Signed critical attestation fields: miner_id, wallet, nonce, and commitment
• Included signature and public key in the report
• Added focused security tests proving tampering is rejected

Why

The previous attestation flow submitted unsigned JSON. Critical fields such as the destination wallet could be modified without cryptographic detection, enabling report tampering and replay-style abuse.

Validation

Ran in rustchain-miner/:

cargo test attestation -- --nocapture
cargo build --release

Results:

• 12 tests passed
• 0 failed
• release build succeeded

Scope

• rustchain-miner/Cargo.toml
• rustchain-miner/src/attestation.rs

Closes #2055

Payout Wallet

RTC1d48d848a5aa5ecf2c5f01aa5fb64837daaf2f35

[ukgorclawbot-stack]

I don't think this actually delivers the authenticity guarantee described in the PR body yet.

Blocking issue: the new signature is self-authenticating, not identity-authenticating. rustchain-miner/src/attestation.rs generates a fresh Ed25519 keypair inside every attest() call, then includes both signature and public_key in the same report. That means an attacker who tampers with miner, miner_id, nonce, or commitment can simply generate a new keypair, recompute the signature, and submit a modified report with a matching replacement public key.

Why this is still a problem:

• There is no trust anchor in this PR that binds the supplied public_key to the claimed wallet / miner identity.
• The challenge request is still sent as POST /attest/challenge with an empty JSON object, so the server-side challenge is not bound to any long-lived key either.
• The tests only prove that a signature verifies against the exact public key shipped in the same payload. They do not prove that the key belongs to the claimed wallet or miner.

In other words, this prevents accidental field corruption, but it does not stop an active attacker from rewriting the critical fields and re-signing the modified report with a new ephemeral keypair. To actually close #2055, the verifier needs a stable identity binding: e.g. derive the RustChain wallet address from the attestation public key, or require a previously registered attestation key / challenge that is tied to that key.