Multi-file web sandbox on a VS Code workbench

[rvcas]

Makes the web sandbox a multi-file VS Code workbench, by abstracting filesystem access so the compiler and language server can run over in-memory files in the browser.

Filesystem abstraction

• starstream-types: a synchronous Vfs trait with NativeFs (std::fs), MemoryFs (in-memory, lexical path normalization) and OverlayFs (a MemoryFs over another Vfs). Synchronous on purpose: in the browser the compiler is Wasm and can't block on JS promises, so hosts populate memory up front. FileSystem wraps a Vfs; FileSystem::new() still means the real filesystem, so CLI call sites are unchanged.
• starstream-compiler: ModuleGraph goes through FileSystem for everything (it used to call std::fs::canonicalize/read_dir directly). Adds ModuleId::ENTRY and ModuleGraphError::import_site. The workspace scan now also skips node_modules/.

Language server

• Analysis reads through an overlay: open buffers > files pushed by the client via a new starstream/syncFiles notification > disk. Unsaved edits in imported files are now seen (previously imports were read from disk).
• Each document records the modules it depends on; editing, closing or changing a file on disk re-checks the open documents that import it. Clients that don't sync files get a dynamically registered didChangeWatchedFiles watcher.
• Cross-file go-to-definition for path-imported names.
• When the module graph can't be built, import errors are reported on the import (including "imported module has errors" for broken direct imports) instead of silently dropping to single-file mode; if nothing is attributable to the file, it still falls back to single-file checking.

VS Code extension

The extension's language server is Wasm in a worker (also on desktop VS Code), so it can't read the filesystem. The extension now pushes workspace .star/.wasm files via starstream/syncFiles and keeps them in sync with a file watcher.

Web sandbox

• The editor is a monaco-vscode-api workbench over an in-memory /workspace seeded with a two-file starter: explorer, search, problems panel, command center. It replaces the single editor and the Diagnostics tab (diagnostics are in the editor and the Problems panel).
• The compile worker takes { files, entry } and compiles through the module graph, like starstream wasm -c, using the active .star file (or main.star) as the entry.

Follow-ups

• Sandbox: compile the workspace like starstream build instead of the active file #242: compile the workspace like starstream build (affects how Run should work).
• Codegen errors in imported modules are rendered against the entry file #243: codegen errors in imported modules are rendered against the entry file (pre-existing in the CLI too).

Testing

• cargo test for starstream-types, starstream-compiler, starstream-language-server, starstream-to-wasm, starstream-cli; clippy (native, and wasm32 for the web crates).
• New tests: MemoryFs/OverlayFs/NativeFs, in-memory module graphs, multi-file language-server analysis, and a server-level test driving initialize → syncFiles → didOpen/didChange/didClose over JSON-RPC.
• Manually in the browser: cross-file diagnostics update from unsaved edits, go-to-definition across files, creating and importing a new file, multi-file compile output.

[SpaceManiac]

UI is a little buggy in places:

• Top-right "Account" button doesn't do anything (should probably just hide it)
• Top-right gear button puts its menu out of view underneath the right side tabs
• Highlight under icon buttons is too small (doesn't cover the whole icon)

These are weird quirks and if there doesn't seem to be a non-hacky solution, we can let them ride for now.