chore(deps): bump typescript to 5.9.3 across the repo

[X-Guardian]

Description

Aligns every workspace package and example on TypeScript 5.9.3, and fixes the two WebAssembly.instantiate call sites (@cdktn/hcl-tools and @cdktn/hcl2json) that fail to compile under newer TS.

Why

The version was drifting. @cdktn/hcl-tools declared ^5.7.3 while the other 10 workspace packages were exact-pinned to 5.4.5, and the 22 example projects were split between 5.4.5 and ^5.7.3. Under yarn workspaces (hoisted node_modules) this drift was invisible — every package got whatever yarn happened to hoist at the root. Under the upcoming pnpm migration (strict, isolated node_modules/.pnpm/ layout) each package resolves its own range, so hcl-tools lands on TS 5.9.3 while everything else lands on 5.4.5 — and the build of hcl-tools fails because TS 5.9.3 resolves WebAssembly.instantiate(buffer, …) differently. We hit this when reproducing the pnpm branch (see "Root cause" below).

The structural problem is the drift itself — over thirty independent pins inviting future divergence. Two changes fix it together:

Change	Effect
Every workspace package and example: "typescript": "^5.0.0"	Each manifest declares only its real constraint ("we compile under TS 5.x").
Root resolutions: "**/typescript": "5.9.3"	Single source of truth for the actual resolved version. Bump = one line.

The root devDep keeps typescript because root-level tooling (tsc-files, typescript-eslint, @typescript-eslint/parser) declares it as a peer.

Root cause of the bridge.ts failures:

In TS 5.7+ Buffer<TArrayBuffer extends ArrayBufferLike = ArrayBuffer> and ArrayBufferView<TArrayBuffer extends ArrayBufferLike = ArrayBufferLike> became generic. In TS 5.9.3 the overload resolver no longer treats Buffer<ArrayBufferLike> as assignable to DOM's BufferSource = ArrayBufferView | ArrayBuffer, so WebAssembly.instantiate(buffer, importObject) falls through from

function instantiate(bytes: BufferSource, …): Promise<WebAssemblyInstantiatedSource>

to the second overload

function instantiate(moduleObject: Module, …): Promise<Instance>

WebAssemblyInstantiatedSource has a .instance property; Instance does not. So result.instance errors with TS2339. The same code is fine under TS 5.4.5/5.8.x because those versions matched the first overload. Both packages/@cdktn/hcl-tools/src/bridge.ts and packages/@cdktn/hcl2json/src/bridge.ts use the same pattern and need the same fix.

This is a prerequisite for #170

Approach: four steps.

1. Loosen per-package ranges to ^5.0.0 in all eleven workspaces (cdktn, cdktn-cli, @cdktn/cli-core, @cdktn/commons, @cdktn/hcl-tools, @cdktn/hcl2cdk, @cdktn/hcl2json, @cdktn/provider-generator, @cdktn/provider-schema, tools/generate-function-bindings, root) and across the 22 examples/typescript/** projects. Honest declarations: each package is built and tested under whatever TS 5.x the root resolves.
2. Pin via root resolutions: add "**/typescript": "5.9.3" alongside the existing **/@types/react and **/jsii resolutions. Future bumps touch one line.
3. Fix both bridge.ts call sites — wrap the Buffer in new Uint8Array(...) before passing it to WebAssembly.instantiate in packages/@cdktn/hcl-tools/src/bridge.ts and packages/@cdktn/hcl2json/src/bridge.ts. This pins the overload to the BufferSource form regardless of how TS resolves Buffer<ArrayBufferLike> against BufferSource in any future TS release.
4. yarn install — refreshes lockfile; every requested typescript range now resolves to 5.9.3.

The bridge.ts changes are required for this bump — without them @cdktn/hcl-tools and @cdktn/hcl2json do not compile under TS 5.9.3.

One incidental fix — examples/typescript/aws-multiple-stacks declared @types/node: 18.11.19 while every other example declared 20.17.51. TS 5.9.3 surfaces the staleness as a structural-typing error ("Interface 'Buffer' incorrectly extends interface 'Uint8Array'"). Bumped to 20.17.51 to match the rest.

Checklist

• I have updated the PR title to match CDKTN's style guide
• I have run the linter on my code locally
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation if applicable
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works if applicable
• New and existing unit tests pass locally with my changes