Provide a Terraform AWS reference deployment and reuse it for release smoke tests

Goal

Make the AWS smoke-test deployment the reference implementation users can deploy themselves. A user with an AWS account and the documented credentials/inputs should be able to run Terraform and get a working open.storage service without manually assembling IAM, networking, storage, compute, bootstrap configuration, or a load balancer.

The primary deliverable is the usable reference deployment. Release smoke tests must exercise that same implementation, rather than a separate CI-only setup that can pass while the documented user path is broken.

User journey

1. Start with a clean AWS account, configure the documented AWS credentials and region, and select a pinned open.storage release.
2. Run the documented Terraform initialization and apply commands with minimal required inputs.
3. Terraform provisions the required IAM, networking, storage, EC2 instance/service, and load balancer. Bootstrap configuration starts open.storage without manual SSH setup.
4. Read Terraform outputs for the usable endpoint and follow the included authentication/client example to create a repository, write through the API, and clone/push with ordinary Git.
5. Keep the deployment for evaluation or remove it using the documented teardown procedure.

Acceptance criteria

• Ship version-controlled Terraform configuration, concise documentation, and a small runnable example that together implement this user journey in a clean user AWS account. State the unavoidable prerequisites clearly; there must be no undocumented organization-specific infrastructure or maintainer-only setup.
• Provision all dependencies for one clearly documented default storage topology, including persistence and the required AWS permissions. Make backend limitations explicit; any S3-only option remains experimental until its separate promotion criteria are met.
• Bootstrap the pinned release and service configuration using cloud-init or an equivalent reproducible mechanism. Define service startup, health checks, restart behavior, and access through the load balancer.
• Expose Terraform outputs for the service URL and useful connection details. Use the load balancer's DNS endpoint where appropriate; do not assume every load balancer provides a stable IP. Consider an optional wildcard-DNS convenience domain, but keep custom-domain ownership optional and document how TLS works without hidden manual steps.
• Provide a complete authentication bootstrap. The server needs the organization's public verification key; the organization/test client retains the private signing key used to mint JWTs. Make key generation, delivery, and client use straightforward without exposing private keys through ordinary Terraform outputs, cloud-init logs, or committed files. Document any sensitive Terraform-state implications of the chosen design.
• Run the automated smoke suite against exactly this reference deployment: create a repo, perform API reads/writes, Git clone/fetch/push, and Git LFS round-trips through the advertised endpoint. Assert authorization failures as well as successful access.
• Use the same Terraform inputs and documented client path for release-candidate checks. Record the tested release artifact/commit, Terraform/provider versions, deployment inputs excluding secrets, logs, and results so a user or maintainer can reproduce failures.
• Validate the clean-account path for release readiness. Separate any AWS account-vending/bootstrap machinery from the deployable reference so ordinary users can bring their existing account. Fresh-account runs should catch assumptions about resources left behind by prior tests.
• Define the recurring CI cadence, ownership, failure notification, and release gate. Proposed starting point: small daily real-S3 coverage, a fuller weekly deployment/recovery run, and full acceptance for each release candidate; finalize according to runtime and budget. Do not maintain a divergent testing-only Terraform implementation.
• Provide dependable cleanup and document whether teardown retains or deletes repository data. Automated runs must verify cleanup, bound runtime/resource usage, and detect leaked resources.

Relationship to launch readiness

This is the implementation and reference-deployment tracking issue for the real-AWS launch blocker. Its smoke tests supply repeatable evidence to that blocker; a successful apply alone does not satisfy full AWS compatibility validation. The existing S3-only promotion tracker retains ownership of experimental-to-supported criteria.

Start with the requested EC2 deployment. EKS can be a separate reference variant if Kubernetes support is part of the intended launch offering.

This issue records the requested work. It does not provision accounts or resources, start scheduled jobs, or authorize cloud spend.