[patch] Recover managed keys after disk loss

[joecorall]

Summary

• attest a newly formatted GCP data filesystem with a root-only, single-use marker bound to the server-assigned data-disk ID
• reconcile orphaned user-managed keys only for module-owned identities, only before consumers start, with durable idempotency state
• restore the central app credential only from unanimous validated distributed copies; caller-supplied identities remain non-destructive
• consume and flush recovery authority immediately after one-shot key convergence, before the persistent timer, Vault, or application startup

Safety properties

• IAM mutation cannot outrun a durable state snapshot
• a snapshot-restored marker cannot authorize a different GCP disk incarnation
• populated, ambiguously labeled, or mismatched filesystems fail closed
• key list and response validation is bounded, exact, and redacted
• supported snapshot restore goes through Terraform and VM replacement so boot config receives the new disk ID

Focused evidence

• GCP Terraform validation and all 41 module tests
• ci/filesystem-prep-contract.sh
• ci/key-rotation-contract.sh
• ci/bootstrap-recovery-contract.sh
• Vault, host security, runtime config, systemd, source-trust, rootfs, config-management, application-env, Compose, and COS jq contracts
• Go vet and tests
• Terraform formatting, Bash syntax, and git diff --check

GitHub CI supplies the full repository lint, ShellCheck, and cloud smoke gates.

Maintainability follow-up

The clean Go boundary is one future cloud-compose-host binary owning the complete IAM/key lifecycle and durable state. This patch deliberately does not add a partial helper because current rootfs/source consumers have no verified host-binary delivery path, and two recovery state machines would be harder to audit.