fix(ssm): lazily create the backing CfnParameter for imported string parameters

[kawaaaas]

Issue (if applicable)

Closes #38396

Reason for this change

ssm.StringParameter.fromStringParameterName() (and fromStringParameterAttributes() / fromStringParameterArn() / StringListParameter.fromListParameterAttributes()) eagerly create a CfnParameter (AWS::SSM::Parameter::Value<...>) to back .stringValue / .stringListValue as soon as the factory method is called, even when the caller never reads that property.

ecs.Secret.fromSsmParameter() only ever reads .parameterArn, which needs no backing CloudFormation resource since it is a plain Stack.of(scope).formatArn(...) string. So importing a parameter by name and using it only for its ARN, the pattern in the issue, leaves a CfnParameter in the template that nothing references. This has always been synthesized. It only became visible once the new default CloudFormation-Validate rule set (#38135, 2.262.0) started flagging it as W2001.

Description of changes

Changed stringValue / stringListValue from an eagerly-assigned field to a memoized get accessor in the following methods.

• StringParameter.fromStringParameterArn()
• StringParameter.fromStringParameterAttributes() (also covers fromStringParameterName())
• StringListParameter.fromListParameterAttributes()

The backing CfnParameter (or CfnDynamicReference, selection logic unchanged) is now only created the first time the property is read, using the same scope/id as before, so the logical ID and template output are unchanged for any code path that already reads it.

Alternative considered. Gating this behind a feature flag. Went without one since nothing is being rejected and no template changes occur for any consumer that already reads .stringValue / .stringListValue. The only difference is that a Parameters entry that was never functional in the first place stops being emitted for ARN-only consumers. Flagging this explicitly for maintainer input, should this go behind a feature flag instead?

Describe any new or updated permissions being added

None.

Description of how you validated changes

Unit tests only, in aws-ssm/test/parameter.test.ts and aws-ecs/test/container-definition.test.ts.

• Existing tests that asserted on the Parameters section without ever reading .stringValue / .stringListValue were relying on the old eager-creation behavior. Updated them to read the property first.
• Added tests asserting the Parameters section is empty when only .parameterArn is used, for each of the three factory methods. This is the direct regression case.
• Added a test for .stringValue's first read happening inside a Lazy.string() producer, asserting the template still comes out correct (see the design decision above).
• Added an ECS test reproducing the issue's exact scenario end to end, using ecs.Secret.fromSsmParameter(ssm.StringParameter.fromStringParameterName(...)), asserting no unreferenced Parameters entry and a correct Secrets[].ValueFrom. Confirmed this test actually catches the regression by running it against the pre-fix code and watching it fail.

No integ test. The only thing to demonstrate here, that there is no unreferenced Parameters entry, is a synth time template concern that the unit tests already cover deterministically. An integ test would add AWS account dependent CI cost without checking anything new.

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.

[kawaaaas]

Exemption Request

This PR does not add an integ test because the change has nothing for an integ test to exercise. The fix only changes when a CfnParameter is created (moved from eager creation at import time to lazy creation on first read of .stringValue / .stringListValue), not what gets created or how any real AWS resource behaves. There is no new CloudFormation resource type, no new deployment behavior, and no new AWS API interaction being introduced.

The only observable effect of this change is a difference in synthesized template shape (whether an unreferenced Parameters entry appears), which is a purely synth time concern. This is already covered deterministically by the unit tests added in aws-ssm/test/parameter.test.ts and aws-ecs/test/container-definition.test.ts, including a test that reproduces the exact scenario from the linked issue end to end and was confirmed to fail against the pre-fix code.

Happy to add one if a maintainer sees a code path this reasoning misses.