feat(cloudformation): harden language server install, caching, cleanup, and startup recovery

[satyakigh]

Problem

The CloudFormation language server installer was not resilient:

• A single failed manifest or bundle request aborted startup; there were no retries.
• Downloads were never verified (no size or hash check), and ZIP entries were extracted without guarding against path traversal.
• A partial or corrupt install left on disk was reused on the next start with no way to recover other than deleting the cache by hand.
• The manifest was cached only in globalState, so an offline start had no fallback to a previously installed version.
• Installer, manifest, and platform logic was split across a ManifestProvider hierarchy, a GitHub-releases adapter, and CloudFormation-specific remapping of win32/windows and legacy-Linux targets.

The JetBrains toolkit already ships a managed installer/launcher with the desired behavior (aws/aws-toolkit-jetbrains#6418); this brings the VS Code toolkit to parity.

Solution

Installation and caching:

• Select the highest compatible, non-delisted version that has a target for the current platform/arch (win32, darwin, linux, linuxglib2.28).
• Retry manifest and bundle downloads three times with exponential backoff; only HTTP 200 is accepted.
• Parse the manifest before atomically caching it to <cache>/aws/language-servers/<name>/manifest.json; fall back to the cached manifest, then to the highest complete installed version, when the network is unavailable.
• Verify each download's size and algorithm:digest hashes before writing anything.
• Preflight every ZIP entry for path traversal, extract entries one at a time (never persisting the archive), preserve POSIX permission bits, and validate the server file and required files after extraction and again after post-install processing.
• Remove a failed install directory and fall back to an installed version on download/extraction failures; hash and no-compatible-version failures propagate.
• Retain the active version plus the highest valid fallback; remove everything else.
• Guard the version string before using it as a directory name.

Startup recovery:

• LspLauncher starts the client and, on a process-start failure, invalidates the resolved installation and retries once.
• Startup failures with known install error codes surface a user-facing message.
• Restart and deactivation dispose the client session explicitly; the status bar command is registered once.

Structure:

• Replace the ManifestProvider hierarchy and GitHub-releases adapter with ResolveManifest function injection; channel (alpha/beta/prod) selection lives only in the CloudFormation adapter, driven by CFN_LSP_ENVIRONMENT (automation defaults to beta, otherwise prod).
• Support a local server bundle via CFN_LSP_BUNDLE; SettingsLspServerProvider now only applies in debug/automation contexts.
• Fetch through cross-fetch (Node http stack) so VS Code proxy settings apply.
• Guard the cfn-init permission update when the executable is absent.

Behavior changes to note:

• Storage moves from <cache>/aws/toolkits/language-servers/... to <cache>/aws/language-servers/... (shared with the JetBrains toolkit); the first start after upgrade re-downloads the server. The legacy directory is not removed yet.
• Debug instances no longer default to the alpha channel; set CFN_LSP_ENVIRONMENT=alpha to opt in.
• clientId is forwarded to the server only when CloudFormation telemetry is enabled and the id is not anonymous.

---

• 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.

[amazon-inspector-ohio]

⏳ I'm reviewing this pull request for security vulnerabilities and code quality issues. I'll provide an update when I'm done

[github-actions]

• 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.

[amazon-inspector-ohio]

✅ I finished the code review, and didn't find any security or code quality issues.