fix(deploy): bump aws-cdk-lib to ^2.258.0 to unblock e2e workspace resolution

[jariy17]

Description

PRs #1465 and #1468 fixed the bundled CLI's readers (@aws-cdk/toolkit-lib and @aws-cdk/cdk-assets-lib) to handle cloud-assembly schema 54. End-user deploys via the global CLI install work correctly — that path resolves cleanly because the global install's node_modules has no parallel aws-cdk-lib to fight over schema hoisting.

However, the e2e test byo-custom-jwt.test.ts continued to fail in CI on main 6/6 with the schema-53 error. Investigation showed this is a workspace-resolution trap, not a customer-facing bug:

                                                  pinned schema dep                hoists where?
agentcore-cli/package.json
  aws-cdk-lib: ^2.248.0     → resolves 2.257.0    ^53.25.0           ┐
                                                                     ├→ top-level: 53.28.0  ❌
  @aws-cdk/cloud-assembly-api  (transitive)        >=53.28.0 (peer)  ┘  binds to 53.28.0

  @aws-cdk/toolkit-lib@1.28.0/node_modules/@aws-cdk/cloud-assembly-schema@54.2.0   ← unreachable
  @aws-cdk/cdk-assets-lib@1.4.10/node_modules/@aws-cdk/cloud-assembly-schema@54.2.0 ← unreachable

byo-custom-jwt.test.ts uses runLocalCLI, which spawns node dist/cli/index.mjs from the workspace root. Node's module resolution starts there. The workspace pulls in aws-cdk-lib@2.257.0 (CLI's own dep, used by src/assets/cdk/ template typechecks and the agent-import translator), whose peer cloud-assembly-schema: ^53.25.0 hoists the schema package at 53.28.0 top-level. @aws-cdk/cloud-assembly-api — also hoisted, with peer >=53.28.0 — then binds to that top-level 53-era schema, even though toolkit-lib and cdk-assets-lib have nested 54.2.0 copies that satisfy their own peers. Synth still throws AssemblyVersionMismatch.

This PR bumps the CLI's own aws-cdk-lib from ^2.248.0 to ^2.258.0. aws-cdk-lib@2.258.0's peer becomes cloud-assembly-schema: ^54.0.0, so npm hoists 54.2.0 at the top level. cloud-assembly-api then binds to the right schema. Resolution chain healed.

Verification

After applying the bump locally:

top-level cloud-assembly-schema: 53.28.0 → 54.2.0  ✅
cloud-assembly-api now resolves: schema 54.2.0       ✅

Re-ran e2e-tests/byo-custom-jwt.test.ts against the patched CLI with CDK_TARBALL set (mimicking the main matrix leg), real AWS credentials, real synth + asset publish + CFN deploy:

✓ e2e: BYO agent with CUSTOM_JWT auth > deploys with CUSTOM_JWT authorizer configuration  270623ms
Tests: 1 passed | 6 skipped (7)

Where it previously threw Cloud assembly schema version mismatch: Maximum schema version supported is 53.x.x, but found 54.0.0.

Changes

• package.json: aws-cdk-lib ^2.248.0 → ^2.258.0 (in both dependencies and peerDependencies).
• npm-shrinkwrap.json: regenerated. aws-cdk-lib 2.257.0 → 2.258.0; top-level cloud-assembly-schema 53.28.0 → 54.2.0.

No source changes.

Type of Change

• Bug fix
• Test infrastructure fix

Why this isn't a customer issue (and why it should still ship)

• End users running the global agentcore CLI binary go through ~/.../@aws/agentcore/node_modules/, not the workspace. That tree has no parallel aws-cdk-lib and resolves schema 54.2.0 cleanly. Customer deploys already work after fix(deploy): bump @aws-cdk/toolkit-lib to read cloud-assembly schema 54 #1465/fix(deploy): bump @aws-cdk/cdk-assets-lib to read schema 54 asset manifests #1468.
• However, this PR also closes a latent fragility: any project that installs @aws/agentcore alongside an old aws-cdk-lib could hit the same hoisting trap (depending on npm version's deduplication heuristics). Pinning the CLI's own aws-cdk-lib peer to ^2.258.0 keeps the workspace resolution clean, makes CI green, and prevents this recurring at the next schema bump.

Testing

• npm run typecheck (passes)
• npm run lint (no new errors)
• npm run test:unit
• e2e-tests/byo-custom-jwt.test.ts > deploys with CUSTOM_JWT authorizer passes against real AWS

Checklist

• I have read the CONTRIBUTING document
• My changes generate no new warnings
• Closes the schema-54 saga: fix(deploy): bump @aws-cdk/toolkit-lib to read cloud-assembly schema 54 #1465 (synth reader) + fix(deploy): bump @aws-cdk/cdk-assets-lib to read schema 54 asset manifests #1468 (asset publisher reader) + this PR (workspace writer alignment)

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[github-actions]

Package Tarball

aws-agentcore-0.17.0.tgz

How to install

gh release download pr-1469-tarball --repo aws/agentcore-cli --pattern "*.tgz" --dir /tmp/pr-tarball
npm install -g /tmp/pr-tarball/aws-agentcore-0.17.0.tgz

[agentcore-cli-automation]

Looks good to merge.

Verified the analysis in the description:

• aws-cdk-lib@2.258.0 indeed pins @aws-cdk/cloud-assembly-schema: ^54.0.0 (visible in the regenerated shrinkwrap), so top-level schema hoists at 54.x and cloud-assembly-api binds to it. The workspace-resolution trap is closed.
• No source uses of aws-cdk-lib in CLI runtime code (only a comment in base-translator.ts), so the version bump is purely for transitive schema alignment — zero behavioral risk.
• The vended src/assets/cdk/package.json keeps ^2.248.0, which is still satisfied by 2.258+ at user install time. No need to touch it.
• The L3 constructs peer (aws-cdk-lib: ^2.248.0) remains compatible with ^2.258.0.
• npm-shrinkwrap.json is in files, so global CLI installs stay deterministic and end-user resolution is unaffected — consistent with the description's claim that this isn't a customer-facing fix.

The peer-dependency tightening from ^2.248.0 → ^2.258.0 is the only thing worth noting for any programmatic consumers of @aws/agentcore, but given the package is still 0.x and primarily a CLI bin, that's acceptable.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	36.35%	11615 / 31945
🔵	Statements	35.67%	12342 / 34593
🔵	Functions	31%	1947 / 6280
🔵	Branches	30.14%	7460 / 24746

Generated in workflow #3524 for commit 56b9260 by the Vitest Coverage Report Action