[Remote rendering 3.5] Server-authoritative color variable lookup tables

### 📝 Description of the feature

**Intent**: The lookup table backing each color variable, the color mapping itself rather than a part's reference to it, becomes server-owned. This is the last piece of the state to invert.

**Context**: Story 3.1 makes each part's reference server-authoritative: which color variable it uses, which component, over what range. the lookup table that reference resolves against still lives client-side on the wasm path, so the server cannot reconstruct what a scene actually looks like, and a user-modiifed color mapping is lost on reload. `RuntimeAppState` reserves a slot for this; this story fills it.

Also move component selection from the mapper to the lookup table (`SelectColorArray(name)` plus `VectorMode` / `VectorComponent`), which is required for magnitude coloring of vector variables. The serialized reference can stay as it is, since `component: -1` already means magnitude, but decide whether to keep that sentinel or mirror VTK's two-field shape.

---

**Known risk**: the lookup table sync issue: On the round-trip spike branch, the LUT state failed to reach the renderer correctly: the framework's client-side cache applied a stale snapshot instead of the state the server delivered. It was diagnosed as a framework-level issue, with no viable local workaround, and has not been retested since.

What kept this from being an issue on `main` is that the client rebuilds its own LUT on every color change, which creates a fresh object (and object ID) every time, and the framework's stale cache is keyed on object ID. This story removes that, so this is the story that creates that condition; it is therefore expected here. See the first comment below for more details on diagnosing the issue.

If we do encounter a similar issue in this user story, it can be deferred until 6.2 [to add link to user story once it's created] - where we retest after bumping the vtk-wasm and trame-vtklocal versions to be current (we are currently a major version behind on both dependencies). Defer by leaving the client owning its own LUT on the wasm path, which is what `main` does today. The spike branch tried making the server own the LUT state and adding a client-side reapply to compensate; this did not reliably work, so is not a recommended stop-gap.

The remote rendering work that follows in Phase 4 and Phase 5 is not dependent on the present user story.

### Acceptance Criteria

- Color LUT is applied on the server side, so on a refresh or reconnect, the LUT is preserved.
- No in-visualizer differences from main.

### 💵 Business Value

_No response_

### 🔗 Useful links and references

_No response_

Start with RuntimeAppState and the current client-owned LUT path on main, then compare it with the round-trip spike branch and the mapper/lookup-table responsibilities. Move component selection with SelectColorArray(name), VectorMode, and VectorComponent while checking the known framework cache behavior. Done means the server-applied LUT survives refresh or reconnect and produces no visual differences from main.

Escrito por el modelo de indexación a partir del texto del issue.