fix(aws): forward whole signals.env to the collector across EC2 paths (#292)

[fheikens]

Problem

The baked AMI signals.service unit
(deploy/aws/imagebuilder/signals-collector-component.yaml) forwarded only
-e SIGNALS_API_TOKEN to the container. Any other SIGNALS_* var a buyer
placed in /etc/signals/signals.env was silently dropped. Found in the #235
AMI launch-test: the dev-only SIGNALS_ALLOW_INSECURE_PG_TLS never reached the
collector, which failed closed and crash-looped. Production RDS use over
verify-full (config in signals.yaml) was unaffected.

Decision (recorded)

Forward-all (vs document-only), chosen by Frank. The collector reads its
full runtime config from SIGNALS_* env, so a buyer tuning any of those must be
able to set it in signals.env without editing the baked unit. Recorded in
specifications/marketplace-ami-image-builder.md as R-AMI-05 with a dated
rationale, plus the security rule R-AMI-06, invariant INV-AMI-04, failure
conditions FC-AMI-04/05, and acceptance cases TC-AMI-06/07.

Change

• Env forwarding: the AMI component and both IaC run paths
  (deploy/aws/terraform, deploy/aws/cloudformation) now docker-run with
  --env-file /etc/signals/signals.env, forwarding the whole file. The
  component keeps EnvironmentFile= so systemd fails cleanly if the file is
  absent. All three EC2 paths now forward env identically (INV-AMI-03 parity).
  CloudFormation was included because it is the third EC2 run path with the
  identical defect; leaving it token-only would create doc-vs-reality drift.
• Security (R-AMI-06 / INV-AMI-04): the token is passed by reference
  only. The IaC paths previously put the token value on the docker command
  line (-e SIGNALS_API_TOKEN="$SIGNALS_API_TOKEN"), visible in the journal and
  ps. They now write it to a root-only (0600) signals.env and pass
  --env-file; the value is never on the command line and never echoed/cat'd to
  a log. /root/signals-api-token is still produced for the operator verify
  step.

Proving secrets are never logged

tests/signals_ami_env_forwarding_test.go asserts, across all three EC2 paths,
that no line cat/echo/tees signals.env to a log stream, no
SIGNALS_API_TOKEN=<value> appears on a docker command line, and no set -x is
enabled. Verified non-vacuous: injecting a cat /etc/signals/signals.env
into terraform and cloudformation each makes the test fail; reverting makes it
pass.

Tests / gates run locally

• go test ./... -count=1 -> all packages pass (tests pkg 16.8s).
• go test ./tests -run TestAMI_ -v -> 3/3 pass.
• bash scripts/preflight.sh gofmt|vet|imagebuilder -> clean.
• terraform fmt -check + terraform validate -> clean / valid.
• shellcheck (default severity) on the added shell + the extracted user-data:
  the only findings are pre-existing SC2154/SC2086 on the Terraform ${var.*}
  interpolation (not real shell); my added lines are clean.
• gitleaks protect --staged (repo .gitleaks.toml) -> no leaks (the token is
  minted at runtime via openssl, no literal committed).

Note: this repo has no yamllint gate; the component's guard is
scripts/check-imagebuilder-component.sh, which still passes.

Acceptance criteria

• Decision recorded (forward-all); component + terraform (+ cloudformation)
  in parity (INV-AMI-03).
• A buyer-supplied SIGNALS_* var in signals.env reaches the collector
  (--env-file forwards the whole file).

Closes #292