Feature: Add KMS signer backend

[tac0turtle]

Summary

Add a cloud KMS implementation of the Signer interface (pkg/signer/signer.go) so operators can manage signing keys in AWS KMS, GCP Cloud KMS, etc. instead of keeping encrypted key files on disk.

Context

The signer package already has a clean interface:

type Signer interface {
    Sign(message []byte) ([]byte, error)
    GetPublic() (crypto.PubKey, error)
    GetAddress() ([]byte, error)
}

Today there are two implementations: file (AES-encrypted Ed25519 key on disk) and noop (in-memory, for testing). The config supports signer_type (file, grpc), which can be extended to awskms, gcpkms, etc.

For production deployments, keeping private keys on disk—even encrypted—is a significant operational risk. A KMS backend would let the key material live in a hardware-backed cloud service, with signing happening remotely via API.

Rough approach

1. Add a new package, e.g. pkg/signer/kms/, implementing signer.Signer.
2. The KMS signer calls the cloud provider's signing API in Sign() and caches the public key from the KMS key metadata for GetPublic()/GetAddress().
3. Wire the new type into SignerConfig and the node startup path.
4. Start with one provider (AWS KMS is a natural first choice), add GCP/Azure later.

Things to figure out

• Ed25519 support varies by provider — AWS KMS added it relatively recently. Need to verify compatibility with libp2p's crypto.PubKey.
• Auth configuration (region, credentials, key ARN/ID) — likely new config fields under signer.*.
• Whether to vendor a cloud SDK or use a lighter-weight approach.