AWS KMS adapter for the Ed25519 signing layer

[osiabu]

nexuscone.signing.Ed25519Signer currently takes a private key in memory. For production deployments, operators want the private key to live in AWS KMS so it never reads out into application memory.

KMS supports SIGN_VERIFY keys with ECC_NIST_P256, ECC_NIST_P384, ECC_NIST_P521, and ECC_SECG_P256K1 curves, plus RSA. KMS does not natively support Ed25519 (curve25519) at time of writing. The adapter therefore needs to choose: (a) use a P-256 KMS key as the signature primitive instead of Ed25519, exposed as a new KmsP256Signer, or (b) use KMS as an envelope-encryption wrapper around a wrapped Ed25519 key that is decrypted in memory at startup only.

This is partly a design issue. The signing path is on the critical path for v0.3.x AWS users and the choice has implications for the verifier (whether it still uses the existing Ed25519Verifier or needs a KmsP256Verifier).

Scope

• Decide between option (a) and option (b) with rationale.
• Implement the chosen path behind a signing.kms submodule.
• Tests against moto or LocalStack for the KMS calls.

Acceptance

• New signer class documented in the README signing section.
• Tests cover the happy path, an expired key, and a permission denial.