fix(rds-postgres-server): grant KMS permissions for storage encryption CMK

[sebastiancorrea81]

Summary

• rds-postgres-server/deployment always creates its own customer-managed KMS key for RDS storage encryption (required for AVD-AWS-0079 compliance, not optional), but specs/requirements/aws granted no kms:* actions at all — create-rds-postgresql-server failed at apply time with AccessDenied on kms:CreateKey.
• Adds a tag-scoped KMS policy to the rds-postgres-server permissions role, gated on the managed-by=nullplatform tag the deployment module already applies to the key it creates — not "Resource": "*" — so the role can create/manage only the CMKs it tags itself and can never touch, disable, or schedule deletion of any other KMS key in the account.
• Exposes the new policy's ARN as rds_kms_policy_arn output, matching the existing rds_policy_arn / rds_sg_policy_arn / rds_secretsmanager_policy_arn outputs.

Why each permission is here (found via live testing against a real account, iterating on each AccessDenied)

• kms:CreateKey / kms:TagResource — create the CMK and tag it.
• kms:GetKeyPolicy — the AWS provider reads the key policy back right after creating aws_kms_key.rds.
• kms:CreateAlias / kms:DeleteAlias / kms:UpdateAlias on both the tag-scoped key statement and a separate alias-ARN-scoped statement — these actions authorize against the alias ARN and the target key ARN as two independent resource checks.
• kms:ListAliases — KMS has no DescribeAlias API; the provider reads an alias back via ListAliases, which only supports "Resource": "*" (no per-item ARN/tag condition exists for this action). Read-only, exposes alias names only.
• kms:CreateGrant / kms:ListGrants / kms:RevokeGrant, kms:EnableKeyRotation / kms:GetKeyRotationStatus, kms:ScheduleKeyDeletion / kms:CancelKeyDeletion, kms:ListResourceTags, kms:DescribeKey — standard lifecycle management of the CMK the role itself created.

Test plan

• Applied against a real AWS account (log-controller-test), with the rds-postgres-server requirements module pointed at this branch.
• Ran create-rds-postgresql-server end-to-end through the actual nullplatform agent — completed successfully (Apply complete: 8 added, 0 changed, 0 destroyed), RDS instance + CMK + alias + Secrets Manager secret all created.
• Verified the secret_kms_key_id (bring-your-own-CMK for the Secrets Manager secret) flow separately with an external customer-managed key — worked without needing any change to this policy.
• Same CMK-creation pattern likely affects aurora-postgres-server (services-postgresql-aurora) — not yet tested/fixed there.