fix(apigateway): duplicate CloudWatch role URN on fresh accounts

[jasonrowsell]

Fixes #6199, likely #6677 too. I was also getting this error

On a fresh AWS account cloudwatchRoleArn is unset, so the guard in setupApiGatewayAccount never short-circuits and every gateway registers an iam.Role under the same logical name — two or more gateways and the deploy fails with Duplicate resource URN. It dies before the ARN is written back, so retries hit the same race. Any account that ever completed a single-gateway deploy short-circuits, which is why this has been hard to reproduce.

Commit 1 registers the role once per process, same as the LambdaEncryptionKey dedupe in function.ts. No logical names change, so existing stacks see no churn.

Commit 2: since terraform-provider-aws v6, destroying aws_api_gateway_account resets cloudwatchRoleArn to null. The setup only exists in the program while the ARN is unset, so bootstrap never converges: set, reset on the next deploy, bootstrap again with a fresh orphan role — the pile-up in #6677. retainOnDelete: true keeps the account-wide setting in place and the cycle converges after the first deploy.

[jasonrowsell]

Calling this one out since it's the only behavioral change for existing users: since terraform-provider-aws v6, destroying aws_api_gateway_account resets cloudwatchRoleArn to null (account.go), and the setting is account/region-wide. Without retainOnDelete here, removing one app resets the role for every other stack in the account — and it's also what stops the bootstrap from converging (#6677): the setup only exists in the program while the ARN is unset, so it gets destroyed on the deploy after bootstrap, the destroy resets the ARN, and the next deploy creates another orphan role.

The trade-off is that a full teardown now leaves the account setting in place, pointing at the (already retained) role. That seemed strictly better than resetting shared account state on sst remove.