fix: resolve high dependabot vulnerabilities

[Simone319]

Summary

Resolves open high-severity Dependabot alerts, and includes the collateral source/test fixes required by the aws-cdk-lib bump those alerts pulled in.

Dependency vulnerability resolutions

• ws (CVE: memory-exhaustion DoS from many HTTP headers): bumped direct deps ^7.5.7→^7.5.11 and ^8.18.0→^8.21.0, and added root resolution ws: >=7.5.11.
• form-data (CVE: unsafe random boundary in multipart requests): added resolution form-data: >=4.0.6 in the root and scripts/ manifests. Transitive (via axios), so a resolution is used.
• js-cookie (CVE: per-instance prototype hijack in assign()): added root resolution js-cookie: >=3.0.7. Transitive (via amazon-cognito-identity-js), so a resolution is used.
• uuid: root resolution uuid: ^11.1.1 (retained).
• aws-cdk-lib: bumped 2.224.0→2.260.0 (root resolution + amplify-data-construct and amplify-graphql-api-construct manifests), with constructs 10.3.0→10.5.0. This is the driver behind the changes below.

aws-cdk-lib 2.260 collateral fixes

• DynamoDB GSI accessor: aws-cdk-lib (as of 2.252) renamed the private globalSecondaryIndexes/localSecondaryIndexes arrays on the DynamoDB L2 Table to _globalSecondaryIndexes/_localSecondaryIndexes (now ArrayBoxes exposing the same find/some surface and element shape). Reading the old names threw a TypeError. Updated to read the renamed field first with a fallback to the public name (Amplify's managed-table construct keeps the public arrays) in:
  • amplify-graphql-relational-transformer/src/resolvers.ts
  • amplify-graphql-transformer-core/src/utils/schema-utils.ts
  • amplify-graphql-conversation-transformer/src/transformer-steps/conversation-resolver-generator.ts
• base-cdk e2e snapshot (test-only): regenerated snapshot keys aws-cdk-lib@2.224.0→aws-cdk-lib@2.260.0.
• custom-logic reverse.ts (test-only): converted the Lambda handler from callback-style to async. Runtime.NODEJS_LATEST resolves to nodejs24.x from 2.260, which dropped support for callback-style handlers.
• jsonServer fixture (test-only): aws-cdk CLI ~2.1101.0→~2.1129.0 (cloud-assembly schema 54 compatibility with aws-cdk-lib 2.260), aws-cdk-lib ~2.224.0→~2.260.0, constructs ^10.3.0→^10.5.0.

Regenerated .jsii, yarn.lock files, and dependency_licenses.txt accordingly.

Test plan

• pr-workflow passes
• e2e-workflow (api_gql + cdk) passes

[sarayev]

The GSI access pattern (table['_globalSecondaryIndexes'] ?? table.globalSecondaryIndexes) is reaching into CDK private internals — which is what broke in the first place when CDK renamed these fields. The fallback helps today, but we're still coupled to implementation details that can change in any minor release.

A more stable alternative would be reading from the L1 CfnTable, which exposes GSIs as public API:

const cfnTable = table.node.defaultChild as CfnTable;
const gsis = Stack.of(table).resolve(cfnTable.globalSecondaryIndexes) ?? [];

This won't break with L2 internal refactors. Also worth centralizing into a single shared utility since the same pattern is duplicated across 3 packages — next time CDK changes something, we'd only need to fix it in one place.

[Simone319]

Thanks @sarayev — agree the private-field coupling isn't ideal long-term. Two issues with the CfnTable approach for this PR, though:

1. It breaks Amplify's managed tables. For the managed DDB strategy the table is AmplifyDynamoDBTable extends Resource, whose node.defaultChild is a CustomResource, not a CfnTable — it keeps GSIs on its own array. So (defaultChild as CfnTable).globalSecondaryIndexes ?? [] resolves to [] there, silently disabling the duplicate-index-name check in resolvers.ts, mis-wiring key schema in schema-utils.ts, and throwing at synth in the conversation transformer. The ?? globalSecondaryIndexes fallback is specifically there to cover both the standard Table and this managed construct.

2. Property casing. Stack.of(table).resolve(cfnTable.globalSecondaryIndexes) renders CFN-cased IndexName/KeySchema, but the callers read .indexName / .keySchema — so find/some would return undefined even on a standard Table without a normalization layer.

Given both, I'd keep the current accessor for this security-fix PR (it's validated e2e-green). Happy to take the centralization idea (single shared helper) as a separate follow-up.

[sarayev]

Thanks for the detailed explanation — makes sense, especially the AmplifyDynamoDBTable case. LGTM, happy to see the centralization follow-up when it comes.

[sarayev]

LGTM