VSIX: stale/incompatible global `osprey` compiler produces false 'undefined variable' diagnostics (no version check)

[MelbourneDeveloper]

Summary

The VSCode extension surfaces a false compiler diagnostic for valid code when the globally-installed osprey binary is out of date relative to the language/extension. There is no version-compatibility check between the extension and the compiler binary it invokes, so a stale binary silently yields misleading errors.

Repro

Open compiler/examples/tested/basics/lists/list_basics.osp in VSCode with the extension active. Line 10 shows:

Error generating LLVM IR: line 10:21: undefined variable 'listAppend': undefined variable

…even though listAppend is a valid, registered builtin.

Root cause

• The current compiler source does define listAppend (and the rest of the persistent-list builtins) — internal/codegen/collection_registry.go. Building from source and running the example compiles cleanly.
• The extension invokes the osprey binary found on PATH (server/src/server.ts, plus hardcoded 'osprey' in client/src/extension.ts:224,279).
• On this machine the global /usr/local/bin/osprey reports Osprey Compiler 1.0.0, which predates the listAppend builtin, while the source tree reports 0.0.0-dev. The stale binary genuinely doesn't know listAppend, so it errors — and the extension faithfully surfaces that error as if the user's code were wrong.

Verification

$ /usr/local/bin/osprey examples/tested/basics/lists/list_basics.osp
Error generating LLVM IR: line 10:21: undefined variable 'listAppend': undefined variable
$ go run ./cmd/osprey examples/tested/basics/lists/list_basics.osp   # current source — compiles fine

Problems

1. No version check — the extension will use any binary named osprey regardless of compatibility (no --version invocation anywhere).
2. Misleading diagnostics — a stale binary makes valid code look broken, pointing the blame at user source instead of the toolchain.
3. Client/server path mismatch — client/src/extension.ts hardcodes 'osprey' and ignores the osprey.server.compilerPath/osprey.server.path settings the server respects.
4. No tests for compiler-path resolution or version compatibility.

Proposed fix

• Add a compiler version/compatibility check in the extension; warn (not a code diagnostic) when the binary is missing or older than the minimum supported version.
• Make client-side invocation honor the same configured compilerPath as the server.
• Tests for both.

Filed from a session investigating the list_basics.osp diagnostic.