feat(keystore): Cloud KMS backend (BackendKind::Cloud, AWS KMS first)

[marthendalnunes]

This was generated by AI during triage.

Agent Brief

Category: enhancement
Summary: Implement the deferred BackendKind::Cloud keystore backend, starting with AWS KMS, shaped so GCP Cloud KMS / Azure Key Vault can follow as siblings.

Current behavior:
The keystore V1 (#104) shipped software, macOS Keychain, Windows Credential Manager, Linux Secret Service, systemd-creds, YubiKey, external-signer, and memory backends. BackendKind::Cloud exists as an enum variant with a canonical "cloud" token, but no backend implements it — SPEC-KEYSTORE explicitly defers cloud KMS past V1 (§3.2, §6.8). Users who keep signing keys in a cloud KMS cannot sign with mkit at all.

Desired behavior:
A Cloud backend that signs Ed25519 via a cloud KMS, selected through the same key-reference and capability-advertising mechanism as the existing backends. First concrete provider: AWS KMS (Ed25519 supported). The provider integration is isolated behind an internal trait so GCP/Azure are additive follow-ups, not rework. Feature-gated so the cloud SDK dependency tree stays out of default builds.

The V1 invariants hold unchanged:

• No change to the Keystore/Signer trait surface — this is an additive backend.
• Wire-format invariant: a cloud-backed signature is byte-equal to a software-backed signature for the same key material (extend the existing golden-vector tests).
• Capabilities are advertised honestly (e.g. device_bound, user-presence) and callers choose; platform unevenness is documented, not papered over.

Key interfaces:

• A new backend module implementing the existing keystore backend trait, dispatched from BackendKind::Cloud.
• Key-reference format for cloud keys (provider + key identifier, e.g. an ARN), following the existing backend:label reference conventions.
• An internal provider trait (sign, get-public-key, describe-capabilities) with the AWS implementation behind a feature; unit tests run against a mock provider — no live cloud calls in the default test suite. Optional live tests may exist behind an env-gated #[ignore] lane, matching the repo's ignored-lane convention.
• SPEC-KEYSTORE — move cloud KMS from "out of scope" to a specified backend section: auth model (ambient provider credentials; mkit never stores cloud secrets), error taxonomy (throttling, permission-denied, key-disabled), and the byte-equality invariant.

Acceptance criteria:

• BackendKind::Cloud resolves to a working backend; listing, describing, and signing work through the standard CLI key-selection paths with an AWS KMS key reference.
• Golden-vector test proves cloud-backed and software-backed signatures are byte-identical for the same key material (via the mock provider).
• Capability advertisement and error mapping covered by unit tests against the mock provider (throttled, denied, disabled-key, wrong-algorithm).
• Default builds and the default test suite are unaffected (feature off ⇒ no cloud SDK deps, no network).
• SPEC-KEYSTORE updated; CLI docs show a cloud key reference end-to-end.

Out of scope:

• GCP Cloud KMS and Azure Key Vault implementations (follow-up issues; the provider trait must accommodate them, that's all).
• TPM 2.0 and additional YubiKey applets (PIV / FIDO2 sk-ed25519) — hardware-dependent, separate issue.
• The opt-in audit log (timestamp, label, op) — still an open design question from feat(keystore): generic OS-native vault for long-term signing keys #104; spin out separately.