ci: remove --no-optional from vscode dependency install (fix #9140)

[vhvb1989]

Summary

Fixes #9140.

The azure-dev - vscode ADO pipeline Test task fails on all three OSes for any PR touching ext/vscode with:

Error: The package "@esbuild/<platform>" could not be found, and is needed by esbuild.

Root cause

The dependency install step used npm ci --no-optional. esbuild ships its platform-specific binary (@esbuild/<platform>) as an optional dependency, so --no-optional drops it, breaking both build:esbuild and the extension-host test runner. Recent global npm (npm i -g npm) strictly honors --no-optional, which is why this regressed silently on ADO while GitHub Actions (using setup-node's bundled npm) stayed green.

Change

Remove --no-optional from the dependency install step in:

• eng/pipelines/templates/jobs/vscode-build.yml (ADO job)
• .github/workflows/vscode-ci.yml (GitHub Actions, for parity)

[azure-pipelines]

Azure Pipelines:
22 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
22 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[github-actions]

📋 Prioritization Note

Thanks for the contribution! The linked issue isn't in the current milestone yet.
Thank you for logging this issue; our team is reviewing it. If you need urgent prioritization, tag @RickWinter and @kristenwomack to let us know.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[jongio]

The same npm ci --no-optional pattern (with a preceding global npm i -g npm) is still in eng/pipelines/templates/jobs/build-scan-vscode.yml line 38. That job runs ci-package.ps1 -> npm run build:esbuild -> node esbuild.mjs, so it'll hit the same missing @esbuild/<platform> failure the moment it runs. It's wired into the build-notice pipeline rather than the PR gate, so it doesn't block here, but it has the identical latent bug. Worth dropping --no-optional there too for parity while you're in this area.