fix(toolkit-lib): hotswap template cache ignores target environment

[Adityaj0]

Closes #1874

Reason for this change

The on-disk hotswap cache (.hotswap-cache/<stackName>.json, in hotswap-template-cache.ts) was keyed only by cloud assembly directory + stack name. Its payload — the last-deployed root template and, for nested stacks, physical resource names — is only valid for the specific account/region it was captured against, but nothing in the key or the data records which environment produced it.

hotswapDeployment() resolves the target environment and then unconditionally trusts the cache for that stack name, regardless of whether it was written for a different account/region. The only invalidation path is a full CloudFormation deployment for the same stack name — switching target environments between hotswap-only sessions (e.g. cdk watch runs against different accounts via AWS_PROFILE, common for environments resolved from CLI credentials at deploy time) never invalidates it.

Concretely: hotswap against Account A, then without an intervening full deploy, switch credentials and hotswap the same stack name against Account B. The stale Account-A cache is returned, so the diff is computed against the wrong deployed state and any hotswap operations that rely on cached physical resource names can target the wrong account's resources.

Description of changes

Fold the resolved environment (account/region) into the hotswap cache key (cachePath), threading it through readHotswapTemplateCache, writeHotswapTemplateCache, and invalidateHotswapTemplateCache, and updating all three call sites (hotswap-deployments.ts, deploy-stack.ts) to pass the stack's resolved environment. A cache entry can now only ever be read back for the environment it was written for; a different environment for the same stack name/assembly directory is treated as a cache miss (falls back to loading the template from CloudFormation), and invalidating one environment's cache no longer touches another's.

Description of how you validated changes

Added a regression test (cache from one environment is never returned for a different environment) to hotswap-template-cache.test.ts that writes a cache entry for environment A and asserts reading it back for environment B returns undefined, reading it back for environment A still returns the cached state, and invalidating environment B's cache doesn't remove environment A's. Verified this test fails against the pre-fix code (the stale cache is returned across environments) and passes after the fix. Updated the existing tests in the same file to pass an environment argument. Ran the full hotswap and deployments unit test suites (494 tests) — all pass. Confirmed tsc --noEmit has no new type errors from this change.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and the DESIGN GUIDELINES

---

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 91.13%. Comparing base (7ff50e7) to head (487002a).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1875      +/-   ##
==========================================
+ Coverage   91.10%   91.13%   +0.03%     
==========================================
  Files          80       80              
  Lines       12205    12205              
  Branches     1742     1744       +2     
==========================================
+ Hits        11119    11123       +4     
+ Misses       1050     1046       -4     
  Partials       36       36              

Flag	Coverage Δ
suite.unit	91.13% <ø> (+0.03%)	⬆️

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.