fix(amazonq): Open multiple VSCode instances crashes Amazon Q Language Server

[jpinkney-aws]

Problem

When running multiple VSCode windows on mac arm64, Amazon Q's language server works correctly in the first window but crashes in additional windows with the error: EXC_CRASH (SIGKILL (Code Signature Invalid))

Root Cause

The crash occurs because:

• The first VSCode window starts the language server and extracts everything (including the node binary from flare)
• When additional VSCode windows are opened, they attempt to re-extract the zip from flare, overriding the current contents
• On mac arm64, overwriting the node binary while it's in use by the first VSCode window can apparently cause code signing validation to fail for the next callers of it
  • This didn't effect windows when I was playing around with it yesterday
  • Weirdly enough, if you start the language server outside of VSCode, unzip servers.zip again, and then spawn a new language server it doesn't seem to have an issue. My guess is there's some weird interplay with electron owning the spawning of the processes

Solution

Instead of forcefully overriding contents in flare, only copy over the file if its necessary

---

• Treat all work as PUBLIC. Private feature/x branches will not be squash-merged at release time.
• Your code changes must meet the guidelines in CONTRIBUTING.md.
• License: I confirm that my contribution is made under the terms of the Apache 2.0 license.

[github-actions]

• This pull request modifies code in src/* but no tests were added/updated.
  • Confirm whether tests should be added or ensure the PR description explains why tests are not required.
• This pull request implements a feat or fix, so it must include a changelog entry (unless the fix is for an unreleased feature). Review the changelog guidelines.
  • Note: beta or "experiment" features that have active users should announce fixes in the changelog.
  • If this is not a feature or fix, use an appropriate type from the title guidelines. For example, telemetry-only changes should use the telemetry type.

[justinmk3]

Does the path/filename give a clue about whether we already extracted/downloaded the identical version before? If so, shouldn't we skip this entirely in that case?

[jpinkney-aws]

Mentioned it in slack, but this is common code that both the initial download uses and the subsequent local resolution of the server uses

When the local resolution is happening it isn't strictly required to unzip, since it should already be unzipped when it was downloading. It's just a fail safe mechanism in-case someone deleted a file manually in the cache