fix: use a customer managed KMS key for RDS storage encryption

[sebastiancorrea81]

Summary

• While adding the same CI checks to services-postgresql-aurora (ci: add PR validation checks and release automation services-postgresql-aurora#2), Trivy's AVD-AWS-0079 flagged that the Aurora cluster relies on the AWS-managed default key instead of a customer managed KMS key for storage encryption.
• RDS's aws_db_instance.main has the same gap (storage_encrypted = true with no kms_key_id) — Trivy just doesn't flag it because its check for aws_db_instance doesn't require an explicit key the way the aws_rds_cluster check does.
• This adds a dedicated aws_kms_key/aws_kms_alias and sets kms_key_id on the instance, for parity with the Aurora fix and so nullplatform controls the key policy/rotation instead of relying on the AWS-managed default.

Test plan

• tofu fmt -check and tofu validate pass on rds-postgres-server/deployment
• terraform plan on an existing instance to confirm this forces a new KMS key + in-place kms_key_id update, not a full instance replacement (AWS allows changing KMS key on an encrypted RDS instance without recreating it, but worth confirming against the actual plan)

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.