This PR updates the TypeScript baseline to 5.9 for consuming the library. This allows the adoption of the new generic Uint8Array<TArrayBuffer> type introduced in that version, improving interoperability with other modern libraries.

Rationale

TypeScript 5.9 made some changes to lib.d.ts, including the introduction of a generic parameter to Uint8Array:

interface Uint8Array<TArrayBuffer extends ArrayBufferLike = ArrayBufferLike> {}

Libraries that interoperate with other frameworks (e.g., Hono) may now expect Uint8Array<ArrayBuffer> as a return type. To enable type compatibility without casting, the SDK should reflect this new definition.

This change:

• Future-proofs the SDK’s typings for TS 5.9+.
• Prevents as Uint8Array<ArrayBuffer> boilerplate in downstream consumers.
• Has no runtime impact.

Affected Areas

• Functions and properties returning Uint8Array are now typed as Uint8Array<ArrayBuffer>. This includes:
  • fastly:secret-store - SecretStoreEntry.prototype.rawBytes()
  • fastly:experimental - includeBytes()
  • TextEncoder.prototype.encode()
  • Stream-related types (CompressionStream, DecompressionStream, Blob, Body)
  • fastly:cache-override - The input and output of bodyTransformFn
• package.json has been updated to make typescript an optional peer dependency, requiring version ^5.9.0 if present.

SemVer

Strictly speaking under semver, this is a breaking change for consumers using TypeScript < 5.9.
However, in the real TypeScript ecosystem, it appears that this kind of "new compiler baseline" is routinely done in a minor or patch bump, especially when:

• It doesn’t change the runtime behavior (which this doesn’t -- it’s purely types),
• The version we're targeting is a non-breaking, released compiler (TS 5.9 is),
• We clearly document the new minimum TS version,
• And we mark it in peerDependencies and CHANGELOG.

TypeScript itself did this between 5.8 -> 5.9, and Hono and countless others have done the same in patch/minor bumps.

So I would think that a release including this would be appropriate as the next minor version of @fastly/js-compute (i.e., 3.36.0), as it seems to be the de facto convention for TypeScript projects that raising the minimum supported TS version isn't a major bump unless runtime behavior or the emitted JS changes.