refactor(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