Extension package size is ~800 MB — LSP 406 MB, preflight 233 MB, node_modules ships dev dependencies (148 MB)

## Problem

Version 0.9.0 (`ms-azuretools.vscode-azureterraform-0.9.0-win32-x64`) unpacks to **~800 MB** on disk. This makes the extension one of the heaviest in the VS Code marketplace and causes slow installs, large auto-update downloads, and significant disk usage.

Breakdown (measured on Windows):

| Path | Size |
|---|---|
| `bin/ms-terraform-lsp.exe` | **406 MB** |
| `bin/aztfpreflight.exe` | **233 MB** |
| `node_modules/` | **149 MB** |
| `out/` (compiled JS) | 2 MB |
| images, misc | ~9 MB |
| **Total** | **~800 MB** |

---

## 1. `ms-terraform-lsp.exe` — 406 MB

The LSP binary is a statically-linked Go binary. At 406 MB it appears to embed the full AzureRM provider schema or vendored Go modules. Some questions:

- Is the binary stripped (`go build -ldflags="-s -w"`)? That alone typically saves 25–30 % for large Go binaries.
- Is UPX compression considered? Go binaries compress well (often 3–4×).
- Does the binary embed a full copy of the AzureRM provider schema? If so, could that be loaded at runtime from a smaller compressed asset instead?
- Is there a server-side download option (download LSP on first use) to avoid shipping it in the VSIX?

---

## 2. `aztfpreflight.exe` — 233 MB

`aztfpreflight` is documented as a tool to run preflight/policy checks against the Azure ARM API (`/providers/Microsoft.Resources/validateResources`). The binary is 233 MB.

- Same strip/UPX questions apply.
- The [aztfpreflight repo](https://github.com/Azure/aztfpreflight) mentions it vendors submodules of `terraform-provider-azurerm` and `go-azure-sdk`. Is that entire vendor tree compiled into the binary?
- Is this feature used by many users? If it's a niche workflow, consider making it an optional download instead of bundling it in the base VSIX.

---

## 3. `node_modules/` — 149 MB containing dev/build dependencies

The `node_modules` folder shipped inside the VSIX contains packages that are purely build-time tools and should never reach end users:

| Package | Size | Category |
|---|---|---|
| `typescript` | **64 MB** | dev — type-checker, not needed at runtime |
| `esbuild` + `@esbuild` | **20 MB** | dev — bundler |
| `prettier` | **8 MB** | dev — formatter |
| `@typescript-eslint` | **4 MB** | dev — linter |
| `eslint` | **3 MB** | dev — linter |

These should be in `devDependencies` and excluded via `.vscodeignore`. Stripping dev dependencies from the VSIX would reduce `node_modules` from 149 MB to roughly a few MB.

---

## Expected behaviour

A typical language-support extension ships in the 5–50 MB range. Even accounting for bundled LSP binaries, 800 MB is extreme. Reasonable targets:

- Strip + compress Go binaries → LSP ~100–150 MB, preflight ~60–80 MB.
- Remove dev dependencies from VSIX → node_modules < 5 MB.
- Consider lazy-download for binaries (especially preflight) to keep the initial install small.

Happy to help investigate further or test compressed builds if that's useful.

Start by reproducing the VSIX size breakdown across bin/ms-terraform-lsp.exe, bin/aztfpreflight.exe, node_modules/, and out/. Inspect the packaging and build configuration to determine which dependencies and binaries are included. Done means a substantially smaller package, with runtime behavior preserved and the issue's size targets measured against the resulting VSIX.

Written by the indexing model from the issue text.