fix: normalize VTKHDF long arrays to fixed width for the wasm client

[LKasianAnsys]

Issue

Addresses #122

Description

This is a temporary workaround for an upstream issue when loading VTKHDF files on macOS and Linux.

• Symptom: on Linux/macOS/Docker, load_state into an empty scene leaves the canvas empty and vtkWebAssembly throws std::bad_alloc; however, it works as expected on Windows. See screenshot below.
• Root cause (upstream VTK, see kitware-ansys/issues/139): vtkObjectManager serializes vtkLongArray / vtkUnsignedLongArray by class name only, without an element width. long is 8 bytes on an LP64 server and 4 bytes in the wasm32 client, so the client lays a 4-byte array over an 8-byte buffer (measured: connectivity [0,1,2] arrives as [0,0,1], GetCellSize(0) == 0).
• Trigger in Visor: save_state writes VTKHDF snapshots; vtkHDFReader returns 64-bit integers, including cell connectivity/offsets, as vtkLongArray on LP64. Polydata reaches the mapper by shallow copy, so the served class is vtkLongArray.
• Fix (workaround): convert the arrays to fixed-width classes (vtkTypeInt64Array / vtkTypeUInt64Array) right after vtkHDFReader reads a file, in file_to_dataset. Nothing else is converted.

Symptom when loading a VTKHDF file:

Choices and tradeoffs.

• Scope is VTKHDF reads only. That covers save/load state (the workflow that hits this consistently) and .vtkhdf files opened by path. .vtp/.vtm/.vtu reads and in-memory datasets are not touched.
• No mutation of caller-owned objects. The conversion runs on the copy file_to_dataset already owns, so no user-held object changes class. A conversion at add_dataset was rejected for that reason.
• Known gap: in-memory datasets with long arrays (for example numpy int64 via numpy_to_vtk on Linux) are still affected by the upstream defect. Validating/rejecting them is deferred.
• Explicit vtkTypeInt64Array, not vtkCellArray.ConvertTo64BitStorage(). It matches the class the working VTP path serves and also covers point/cell/field data; ConvertTo64BitStorage covers cell arrays only.
• wasm32 client kept. A wasm64 build reads the data correctly, but Visor bundles wasm32 by design.
• Cost: converted arrays are copied once at read time; already fixed-width data costs a class-name check per array. On Windows the reader never yields vtkLongArray, so the helper is a no-op there.
• Field-data rebuild: vtkFieldData has no replace-in-place, so arrays from the first converted one onward are removed and re-appended in order; active-attribute roles are restored.

Removal. Delete client_dataset_normalizer.py, its import and the if is_hdf: block in file_to_dataset.py,
tests/unit/vtk/io/test_client_dataset_normalizer.py, and test_file_to_dataset_normalizes_long_arrays_only_for_vtkhdf once the VTK version Visor depends on serializes platform-width arrays with a fixed element width. The module docstring and the call site say the same.