remote-signer: AWS Nitro Enclave deployment path

PR #25 covers the `aws-kms` backend: key encrypted at rest, decrypted via KMS, held in signer process memory on the validator host. For mainnet/institutional validators we want the `aws-nitro` backend — key only ever decrypted inside an attested enclave, never in host memory, KMS decrypt gated on enclave attestation.

Both the ansible role and helm sidecar explicitly reject `aws-nitro` (needs host enclave devices; see the signer repo's `docs/aws-nitro.md` and `scripts/e2e-aws-nitro.sh`). Needed here:
- terraform: Nitro-capable instance type for validators (e.g. m6i/c6a with `enclave_options { enabled = true }`), enclave resource allocation
- ansible: role variant that runs the enclave image + host proxy instead of the plain container
- docs: threat-model comparison aws-kms vs aws-nitro so users pick deliberately

The signer repo already has the enclave build + e2e; this is deployment wiring.

Start with docs/aws-nitro.md and scripts/e2e-aws-nitro.sh in the signer repository, then inspect this repository's Terraform validator definitions, Ansible role, and Helm sidecar rejection. Done means validators can allocate Nitro enclaves and deploy the enclave image with its host proxy, while the documentation compares aws-kms and aws-nitro threat models.

Written by the indexing model from the issue text.