build: Update dependencies on @microsoft/api-extractor to version 7.50.1

[Josmithr]

Also updates typescript and @types/node in api-markdown-documenter to be compatible with the api-extractor update.

This PR does not update dependencies under server/routerlicious due to the same version incompatibilities. Those packages will need to be addressed separately.

PR Overview

This pull request updates dependency versions in the pnpm lockfile to ensure compatibility with the new @microsoft/api-extractor@7.50.1 release. Key changes include updating @microsoft/api-extractor (and its model), bumping TypeScript from 5.4.5 to 5.7.3, and synchronizing related package versions (e.g. fs-extra, @types/node, and others) across the lockfile.

Reviewed Changes

File	Description
common/lib/protocol-definitions/pnpm-lock.yaml	Updated dependency versions to support @microsoft/api-extractor@7.50.1

Copilot reviewed 107 out of 107 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (2)

common/lib/protocol-definitions/pnpm-lock.yaml:4507

• The TypeScript version has been updated to 5.7.3. Please verify that all consuming tooling and dependent packages are compatible with this upgrade to avoid potential breaking changes.

typescript@5.7.3:    resolution: {integrity: sha512-84MVSjMEHP+FQRPy3pX9sTVV/INIex71s9TL2Gm5FG/WG1SqXeKyZ0k7/blY/4FdOzI12CBy1vGc4og/eus0fw==}

common/lib/protocol-definitions/pnpm-lock.yaml:11

• The patched dependency for @microsoft/api-extractor is updated to 7.50.1; please confirm that the accompanying patch file and its associated hash are correct and intentional.

'@microsoft/api-extractor@7.50.1':

[jason-ha]

Are we not making progress on getting our patches into api-extractor?

[jason-ha]

Someone's dev dependencies are bleeding through? I would not have expected a test update like this.

[jason-ha]

This is the one place I see the qualification change. I guess jest will use the latest version of typescript it finds.

[alexvy86]

jest-environment-puppeteer doesn't specify any direct dependencies of any kind on typescript, seems like it comes through its dependency on cosmiconfig, which does declare a devDep on "typescript": "^5.2.2" and got a new entry with typescript 5.7.3.

[Josmithr]

Are we not making progress on getting our patches into api-extractor?

Unfortunately, no not really. We haven't really gotten any implementation support from them. I've been able to get advice on how to fix some issues myself, but that's been mostly the extent. I've fixed some issues myself, but I haven't had the necessary time scheduled to do much.

[jason-ha]

I looked into the errors api-extractor produces with this update and it seems like an api-extractor issue.
I thought it might be an updated typescript version. I bumped the local typescript version to 5.7.3. If just a TypeScript issue, then there would be a similar error, but there was no error.
Despite the file includes errors, there are other complaints and the output is updated. The results are not as preferred. Unsure if we'll get the results desired, once project understanding is straightened out.

Here is a sample of reference errors that look suspect:

Error: src/core-interfaces/exposedUtilityTypes.ts:11:8 - (TS6307) File 'FluidFramework/packages/framework/presence/src/core-interfaces/jsonSerializationErrors.ts' is not listed within the file list of project ''. Projects must list all files or use an 'include' pattern.
  The file is in the program because:
    Imported via "./jsonSerializationErrors.js" from file 'FluidFramework/packages/framework/presence/src/core-interfaces/exposedUtilityTypes.ts'

It says not listed within the file list of project '' - that empty project name suggests there is something questionable in api-extractor hosting of typescript.

[jason-ha]

I took a guess that merging with #21725, which simplifies presence package structure, might help clear up some errors.
We get very lucky and indeed it will clear up all of the reference/includes errors. It looks like api-extractor's typescript setup can handle one level of self-references, but not two.
After that, api-extractor is discovering the trick I had used to "abuse" some self-referencing and hide the types that don't need to be exposed. So, we'll have to reveal these types after all. I can make the changes after #21725 is merged.