VTKHDF round-trip of a degree-3 mesh is not exact

`test_read_write_higher_order_mesh[3]` compares the volume and surface of a
degree-3 tetrahedral sphere mesh against the same mesh written to VTKHDF and
read back. The two differ by more than rounding:

```
np.isclose(4.188993453979492, 4.188951256407762, rtol=1e-05)
```

That is 1.007e-5 relative. Both meshes are `float64` whatever the build's
default scalar type, so this is far beyond floating-point rounding. Orders 1
and 2 round-trip cleanly; only degree 3 shows it.

It surfaced when the BLAS provider changed in the Spack CI legs, which
suggests it tracks the mesh gmsh produces rather than the arithmetic of the
comparison — gmsh links LAPACK, so its high-order node placement moved, and
the round-trip error moved with it. That would mean the inaccuracy is present
for other degree-3 meshes too and simply sat under the tolerance before.

The check in the test is currently set to `rtol=1e-4`, which is enough to
catch gross errors but does not certify the round-trip.

Worth establishing whether the geometry read back differs from what was
written (node ordering or permutation for the interior degrees of freedom
would be the obvious suspect), or whether the difference is introduced on
write.

Start with test_read_write_higher_order_mesh[3] and reproduce the degree-3 discrepancy with the stricter tolerance. Compare the geometry before writing with the geometry after VTKHDF readback, then inspect the VTKHDF write and read paths for node ordering or interior-degree-of-freedom permutations. Done means identifying whether the error is introduced on write or read and making the round-trip pass a tighter accuracy check.

Written by the indexing model from the issue text.