AMI systemd unit forwards only SIGNALS_API_TOKEN, not other SIGNALS_* env

[fheikens]

Observation

The EC2 Image Builder component's baked signals.service unit
(deploy/aws/imagebuilder/signals-collector-component.yaml) passes only
-e SIGNALS_API_TOKEN to the container. Other SIGNALS_* environment
variables a buyer might place in /etc/signals/signals.env are not
forwarded to the collector.

Found during the #235 AMI launch-test: a non-TLS test DB needs the dev-only
SIGNALS_ALLOW_INSECURE_PG_TLS=true, which the unit does not forward, so the
collector failed closed (correct behaviour) and the unit crash-looped. The
designed production path (RDS over verify-full TLS, config in
signals.yaml) is unaffected — this only bites dev/non-TLS or future tuning
env.

Options

• Forward the whole signals.env via systemd EnvironmentFile semantics to the
  container (e.g. --env-file /etc/signals/signals.env), OR
• Explicitly document the unit as TLS-production-oriented (token is the only
  runtime env; all other config via signals.yaml).

Non-blocking for the AMI product (production RDS use works). Mirror any change in
deploy/aws/terraform for INV-AMI-03 parity.

Acceptance criteria

• Decision recorded (forward-all vs document-only); component + terraform stay in parity.
• If forwarding: a buyer-supplied SIGNALS_* var in signals.env reaches the collector.

[fheikens]

Scope note (authorization record): the fix in PR #299 is extended beyond the imagebuilder + Terraform paths named above to also cover the third EC2 path, deploy/aws/cloudformation/signals-rds-iam.yaml. All three carried the same two defects — env-only token forwarding, and -e SIGNALS_API_TOKEN="$SIGNALS_API_TOKEN" leaking the token value onto the docker command line (process table / journal). Fixing only two of three would leave a live secret leak and doc-vs-reality drift, so all three are remediated together in this issue. Extension approved by the maintainer 2026-07-20.