fix: add KMS IAM policy to the aurora-postgres-server permissions role

[timossileandro]

What

Adds a <prefix>-rds-kms-policy IAM policy — and its role attachment — to the
aurora-postgres-server AssumeRole permissions role in
specs/requirements/aws/main.tf.

Why

0.0.2 moved Aurora storage encryption to a customer managed key
(5f71cc7, AVD-AWS-0079): deployment/main.tf now creates aws_kms_key.aurora +
aws_kms_alias.aurora and feeds the key ARN into aws_rds_cluster.main. The
permissions role that the agent assumes was never updated to match, so the KMS
calls in the deployment plan are denied — the service can't complete its first
apply, and a destroy leaves the key and alias behind.

What the policy grants

• KmsCreateAndList — kms:CreateKey, TagResource, ListKeys,
  ListAliases. Resource * because there is no key ARN to scope to before
  CreateKey returns.
• KmsManageKey — describe / key policy / rotation / tags / lifecycle
  (including ScheduleKeyDeletion and CancelKeyDeletion), scoped to keys in
  the current account via data.aws_caller_identity.current.account_id.
• KmsCreateGrantForRds — CreateGrant / ListGrants / RevokeGrant,
  gated on kms:GrantIsForAWSResource = true. RDS creates a grant on the CMK
  when it attaches the key to the cluster; without this, cluster creation fails
  with a KMS access error even though the key already exists.
• KmsManageAlias — CreateAlias / UpdateAlias / DeleteAlias on
  alias/nullplatform-aurora-* (the alias pattern deployment/main.tf uses)
  plus the key resource, since the alias APIs authorize against both the alias
  and its target key.

Every resource is behind count = local.iam_create ? 1 : 0, in line with the
other policies in the module, so accounts that bring their own role are
unaffected.

Scope and impact

• Single file touched: aurora-postgres-server/specs/requirements/aws/main.tf.
  No changes to deployment/, workflows, or specs; aurora-postgres-db is
  untouched.
• Existing installations must re-apply specs/requirements/aws to pick up the
  new policy and attachment. The role name and trust policy are unchanged, so
  nothing needs to be re-registered on the nullplatform side
  (identity-access-control provider and selector stay the same).
• No new Trivy suppressions: the wildcard-resource pattern already exists in the
  RDS, security group and Secrets Manager policies in this module.

Verification

• tofu fmt -check and tofu validate in
  aurora-postgres-server/specs/requirements/aws.
• tofu plan on a test account: the plan adds one aws_iam_policy and one
  aws_iam_role_policy_attachment, with no changes to the existing role or
  policies.
• End to end: create an aurora-postgres-server service on an account whose
  role comes from this module and confirm the cluster comes up with the CMK,
  then delete it and confirm the key is scheduled for deletion and the alias is
  removed.

[sebastiancorrea81]

lgtm