Migrate sensitive ECS environment variables to Secrets Manager

## Summary

Approximately 12 variables marked `sensitive = true` in Terraform variables.tf are currently passed as plain-text `environment` entries in ECS task definitions rather than through the `secrets` block backed by AWS Secrets Manager.

## Context and Risk Assessment

While this is a security hygiene improvement, the current exposure is limited:

- **Terraform state file**: stored locally (not committed to git), so access requires SSH to the deployment host
- **ECS Console / API**: viewing task definition JSON requires appropriate IAM permissions (ecs:DescribeTaskDefinition)
- **CloudTrail**: API call logs that include task definition payloads require IAM access to CloudTrail and the specific trail/S3 bucket

These values are not publicly accessible. This is a defense-in-depth improvement, not an active vulnerability.

## Affected Variables

| Variable | Service | Purpose |
|----------|---------|---------|
| `REGISTRY_API_TOKEN` | registry | Static bearer token for service-to-service auth |
| `REGISTRY_API_KEYS` | registry | JSON object of multi-key static tokens |
| `FEDERATION_STATIC_TOKEN` | registry | Federation peer authentication |
| `FEDERATION_ENCRYPTION_KEY` | registry | Fernet key for federation payload encryption |
| `ANS_API_KEY` | registry | Agent Name Service API key |
| `ANS_API_SECRET` | registry | Agent Name Service API secret |
| `REGISTRATION_WEBHOOK_AUTH_TOKEN` | registry | Webhook delivery authentication |
| `REGISTRATION_GATE_AUTH_CREDENTIAL` | registry | Admission gate authentication |
| `REGISTRATION_GATE_OAUTH2_CLIENT_SECRET` | registry | Gate OAuth2 client secret |
| `GITHUB_PAT` | registry | GitHub private repo access token |
| `GITHUB_APP_PRIVATE_KEY` | registry | GitHub App private key |
| `GF_SECURITY_ADMIN_PASSWORD` | grafana | Grafana admin password |

## Proposed Approach

Migrate one service at a time, starting with the registry (most sensitive values):

1. Create Secrets Manager secrets for each variable (or group related ones into a single JSON secret)
2. Update the task execution role policy to grant `secretsmanager:GetSecretValue` for the new secrets
3. Move variables from `environment` block to `secrets` block using `${arn}:key::` syntax for JSON secrets
4. Verify task starts successfully and reads the values correctly
5. Repeat for other services

## Risk of Breaking Things

This change has deployment risk: if the secret ARN, JSON key path, or IAM permissions are misconfigured, the ECS task will fail to start entirely (not a graceful degradation). Each migration should be tested with a single forced new deployment before proceeding to the next variable.

## Existing Pattern to Follow

`SECRET_KEY` and `KEYCLOAK_CLIENT_SECRET` are already correctly using the `secrets` block (see `ecs-services.tf` lines ~160-180). Follow the same pattern.