fix(autoscaling): StepScalingPolicy emits spurious cooldown deprecation warning

[Zelys-DFKH]

Issue #37833

Fixes #37833

Reason for this change

Every StepScalingPolicy (and every call to AutoScalingGroup.scaleOnMetric) prints two JSII deprecation warnings for StepScalingActionProps#cooldown during synthesis, even when the user never set that property. In a stack with many step-scaled groups, this floods build output and buries legitimate deprecation signals.

The root cause: StepScalingPolicy unconditionally writes cooldown: props.cooldown into the props passed to StepScalingAction, so the key is always present even when the value is undefined. JSII's generated deprecation checker uses a key-existence test ('cooldown' in p) rather than a value test, so the warning fires whenever the key appears, regardless of its value.

Description of changes

In packages/aws-cdk-lib/aws-autoscaling/lib/step-scaling-policy.ts, replaced cooldown: props.cooldown with a conditional spread in both the lowerAction and upperAction constructor calls:

...(props.cooldown !== undefined ? { cooldown: props.cooldown } : {})

When cooldown is not set, the key is absent from the props object. The JSII key-existence check returns false and no warning fires. When the user explicitly passes cooldown, it is still forwarded and the deprecation warning fires correctly.

No CloudFormation output changes. StepScalingAction already discards the cooldown value and does not pass it to CfnScalingPolicy.

Description of how you validated changes

Added two tests to packages/aws-cdk-lib/aws-autoscaling/test/scaling.test.ts:

1. scaleOnMetric without cooldown does not emit cooldown deprecation warning — verifies no @aws-cdk/aws-autoscaling:cooldownOnStepScaling CDK annotation is added to the stack.
2. scaleOnMetric with cooldown emits cooldown deprecation warning — verifies the annotation is present when cooldown is explicitly set, confirming the intentional deprecation path is preserved.

One caveat: JSII's key-existence check ('cooldown' in p) only runs in compiled output, not in the ts-jest environment. The tests above cover the related CDK annotation behavior (StepScalingAction's if (props.cooldown) guard). The fix can be verified end-to-end by running cdk synth on the reproduction case in the issue and confirming the warnings no longer appear.

All 20 tests in scaling.test.ts pass.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

The pull request linter fails with the following errors:

❌ Fixes must contain a change to an integration test file and the resulting snapshot.

If you believe this pull request should receive an exemption, please comment and provide a justification. A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed, add Clarification Request to a comment.

✅ A exemption request has been requested. Please wait for a maintainer's review.

[Zelys-DFKH]

Exemption Request

This fix suppresses a spurious JSII deprecation warning that fires during synthesis even when the user never sets the cooldown property. The change is entirely in the L2 construct's TypeScript constructor — it uses a conditional spread so the key is absent from props when cooldown is undefined, which prevents JSII's key-existence check from falsely triggering.

There are no CloudFormation output changes: StepScalingAction already discards the cooldown value before it reaches CfnScalingPolicy. An integration test snapshot would be byte-for-byte identical before and after this change, so updating one would add noise without adding signal.