fix(toolkit-lib): drop the deep clone used to remove one metadata key

[Adityaj0]

Fixes #1823

Reason for this change

stripConstructPath removes Metadata['aws:cdk:path'] before a resource is hashed, and does it by round-tripping the whole resource through JSON.parse(JSON.stringify(...)). The cost scales with the size of the resource rather than with the one key being removed, and every CDK-generated resource carries that key — including the large ones (inline policy documents, state machine definitions, inline Lambda code).

The clone is not needed for correctness. The result is only read: it goes straight into stripReferences, which builds its own new tree. And a RefactoringContext runs computeResourceDigests four times per environment (deployed and local stacks, in both graph directions), so each resource is cloned four times per refactor.

Description of changes

Shallow-copy the resource and its Metadata map instead:

const { 'aws:cdk:path': _, ...metadata } = resource.Metadata;
return { ...resource, Metadata: metadata };

Same output, same guarantee that the caller's template is left untouched, and the cost no longer depends on how big the resource is.

Description of how you validated changes

• Digests are byte-identical before and after: asserted the full digest map for both graph directions against the current implementation's output on CDK-shaped templates.

• New regression test covering the properties this relies on: metadata other than the construct path still contributes to the digest, the caller's Metadata object is not modified, and repeated calls are stable.

• All 55 tests under test/api/refactoring/ pass.

• Benchmark — synthetic CDK-shaped templates (nested policy documents, tags, Ref/Fn::GetAtt cross-references, DependsOn, aws:cdk:path on every resource), timing the four computeResourceDigests calls one RefactoringContext performs. Cold node process per measurement, min of 7 runs:

  template shape	JSON size per side	before	after	improvement
  1 stack × 200 resources	0.6 MiB	50.0 ms	38.1 ms	23.8%
  5 stacks × 200 resources	3.0 MiB	236.9 ms	185.2 ms	21.8%
  10 stacks × 400 resources	22.2 MiB	1534.3 ms	1140.8 ms	25.6%

Note: #1824 covers a second, larger inefficiency in the same four passes (each resource's property hash is recomputed once per graph direction). The two changes are independent and compose; this one is the smaller, self-contained half.

Checklist

• This change contains a major version upgrade for a dependency and I confirm all breaking changes are addressed
  • Release notes for the new version:

---

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

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.91%. Comparing base (927a6cc) to head (57a2a19).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1826      +/-   ##
==========================================
- Coverage   90.92%   90.91%   -0.02%     
==========================================
  Files          80       80              
  Lines       12226    12226              
  Branches     1750     1750              
==========================================
- Hits        11117    11115       -2     
- Misses       1073     1075       +2     
  Partials       36       36              

Flag	Coverage Δ
suite.unit	90.91% <ø> (-0.02%)	⬇️

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.