`cargo run` fails on WebAssembly target due to `CARGO_BUILD_TARGET` leaking into `rustc_codegen_spirv` build

### Summary
When running the standard `cargo run` development workflow, the build fails while compiling the web frontend (`wasm-pack build ./wrapper --dev --target=web`).

The failure occurs in the `raster-nodes-shaders` crate's `build.rs` script. The build script attempts to compile the `rustc_codegen_spirv` compiler backend, but the parent `CARGO_BUILD_TARGET=wasm32-unknown-unknown` environment variable is inherited by the inner `cargo` build. Because WebAssembly does not support dynamic libraries (`dylib`), the inner build fails.

### Error Output
```text
[INFO]: 🎯 Checking for the Wasm target...
[INFO]: 🌀 Compiling to Wasm...
Compiling raster-nodes-shaders v0.1.0 (../Graphite/node-graph/nodes/raster/shaders)
error: failed to run custom build command for `raster-nodes-shaders v0.1.0 (../Graphite/node-graph/nodes/raster/shaders)`

Caused by:
...
error: cannot produce dylib for `rustc_codegen_spirv v0.9.0 (https://github.com/Firestar99/rust-gpu-new?rev=c12f2161...#c12f2161)` as the target `wasm32-unknown-unknown` does not support these crate types
```

### Steps to Reproduce
1. Clone the repository.
2. Ensure Node.js and Rust prerequisites are installed.
3. Run `cargo run`.
4. Observe the build crash when `wasm-pack` reaches `raster-nodes-shaders`.

### Proposed Solution
The inner build initiated by `cargo_gpu::Install` inside `node-graph/nodes/raster/shaders/build.rs` needs to compile for the host OS, not the WebAssembly target.

Clearing the `CARGO_BUILD_TARGET` environment variable inside `build.rs` before it kicks off the `cargo_gpu` build resolves the issue and allows the compilation to succeed:

```rust
// node-graph/nodes/raster/shaders/build.rs

// Inside main():
unsafe { std::env::remove_var("CARGO_BUILD_TARGET"); }

// ... followed by the existing cargo_gpu::Install::from_shader_crate(...) logic
```

### Environment
* **OS:** macOS 26.3.1 (Build 25D2128)
* **Rust Version:** rustc 1.92.0 (ded5c06cf 2025-12-08)
* **Node.js:** v22.21.1

### 🤖 AI disclosure

I used Gemini to help me understand the error message. This message and the fix are mine.

Start with node-graph/nodes/raster/shaders/build.rs and the cargo_gpu::Install::from_shader_crate(...) call. Reproduce the failure with cargo run, then verify the inner build uses the host target rather than the inherited WebAssembly target. Done means the standard cargo run workflow completes past raster-nodes-shaders without the dylib error.

Written by the indexing model from the issue text.