fix(toolkit-lib): cdk import fails on a stack that contains non-ASCII characters

[HuzaifaChaudary]

Closes #1915

Reason for this change

cdk import builds the IMPORT change set from the deployed template as returned by GetTemplate, and that API flattens every codepoint above \u007f to a literal ?. The submitted template then carries a ? where the deployed resource really holds the original character, so CloudFormation rejects the import and names a resource the user never touched:

You have modified resources [<LogicalId>] in your template that are not being imported.

cdk diff has compensated for the same mangling since aws/aws-cdk#25912, but that lives in the diff formatter, so the import path never saw it. As @pahud noted on the issue, the import's own pre-flight diff prints Omitted 1 changes because they are likely mangled non-ASCII characters and then submits the mangled template anyway.

Description of changes

The deployed template is walked against the local one before the additions go in, and a deployed string is replaced by the local one only when mangleLikeCloudFormation(local) equals it. Anything else is left as deployed, so a real modification is still submitted as a modification and still fails loudly. This is the first of the two approaches @pahud suggested; rebuilding from the synthesized template would also work but changes more than the mangling case.

Two things worth flagging:

• it heals property values , not property names . a mangled key would need the same treatment and i have not seen a report of one , so i left it out rather than guess .
• the helper lives in importer.ts beside the existing addDefaultDeletionPolicy . if you would rather have it in cloudformation-diff next to mangleLikeCloudFormation , say so and i will move it .

Describe any new or updated permissions being added

None.

Description of how you validated changes

Two unit tests in test/api/resource-import/import.test.ts: one asserts the submitted change set keeps the em dash where GetTemplate returned ?, and one asserts a genuinely changed non-ASCII string is still submitted as deployed, so the healing cannot swallow a real edit. The first fails without the change.

jest on the package is 1986 passed of 2049. The 62 failures are in bootstrap, sdk-provider and notices/cached-data-source and are identical on an unmodified tree here, so they are this machine, not this change. eslint is clean on both changed files; the one error it reports for the package is in lib/api/aws-auth/base-credentials.ts, which this branch does not touch. I could not run the cli-integ suite, it needs a real AWS account.

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

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[mrgrain]

Nice, thank you! This needs an integration test though.

[mrgrain]

Nice, thank you! This needs an integration test though.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.47%. Comparing base (ca64124) to head (e79230a).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1988   +/-   ##
=======================================
  Coverage   91.47%   91.47%           
=======================================
  Files          80       80           
  Lines       12675    12675           
  Branches     1792     1792           
=======================================
  Hits        11595    11595           
  Misses       1042     1042           
  Partials       38       38           

Flag	Coverage Δ
suite.unit	91.47% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[HuzaifaChaudary]

added one in cli-integ/tests/cli-integ-tests/import . it follows the queue import test , and the importable stack now takes an INCLUDE_NON_ASCII_POLICY flag that adds a managed policy with an em dash in its description , the same shape as the report in #1915 . it deploys that with a retained queue , drops the queue , imports it back and expects IMPORT_COMPLETE .

i could not run it against an account , i do not have one set up for the integ suite . what i did check is that it compiles with the package build , eslint is clean , and the app synths the policy with the em dash intact . the push will likely need the workflows approved again .