Uniform access ergonomics: get!() returns a guard, not a value

## Description

`get!(U_TIME)` returns `ModuleVarReadGuard` which `Deref`s to `&T`. This means the result cannot be used directly in arithmetic expressions (`+`, `*`, `/`, etc.) because operator traits are implemented on `T`, not on the guard or `&T`.

Users must work around this with identity type constructors:

```rust
// Scalars: wrap in f32()
let time = f32(get!(U_TIME));

// Vectors: reconstruct through swizzle accessors
let res = vec2f(get!(U_RESOLUTION).x(), get!(U_RESOLUTION).y());

// Then use the local copies in arithmetic
let st = frag_coord.xy() / res * 3.0;
```

On the WGSL side, `f32(U_TIME)` and `vec2f(U_RESOLUTION.x, U_RESOLUTION.y)` are valid but redundant identity constructors.

This is the most common friction point when writing shaders with uniforms in expressions.

## Possible approaches

1. **Implement arithmetic ops on the guard**: Add `Add`, `Sub`, `Mul`, `Div` (and their assign variants) on `ModuleVarReadGuard` where `T: Copy`, delegating through deref+copy. This is the least invasive change.

2. **Have `get!()` return `T` directly**: Copy the value out of the lock instead of returning a guard. Uniform values are read-only from shaders so the guard's lifetime semantics aren't needed. The lock would still be held briefly during the copy.

3. **Introduce a `load!()` macro**: A new macro that does `{ let v = *get!(X); v }` on the Rust side but emits just `X` in WGSL, avoiding both the guard ergonomics issue and any concern about WGSL dereference syntax.

Start by tracing the get!() macro and ModuleVarReadGuard behavior described in the issue, then compare the three proposed approaches for Rust-side uniform access and WGSL emission. Done means the chosen design allows uniform values to participate naturally in arithmetic while preserving the expected WGSL output and lock semantics.

Written by the indexing model from the issue text.