TSDF GPU tests panic in bytemuck: repr(align(16)) readback misalignment

[rajgandhi1]

Three GPU TSDF tests fail on Windows with a bytemuck panic (buffer size / cast mismatch):

• tsdf::tests::test_tsdf_surface_extraction
• tsdf::tests::test_tsdf_multiple_integrations
• tsdf::tests::test_tsdf_color_integration

thread 'tsdf::tests::test_tsdf_color_integration' panicked at bytemuck-1.25.0/src/internal.rs:33:3

Details

• Reproduces on main independently of any feature branch — this is a pre-existing issue, not a regression.
• Only the TSDF path is affected; GPU normals, filtering, nearest-neighbor, segmentation tests all pass.
• Likely a mismatch between the buffer size allocated and the size bytemuck expects when casting the GPU readback (possibly std430 padding / struct alignment on this adapter).

Interim action

These three tests are marked #[ignore] so CI stays green; the code path itself is unchanged. Remove the #[ignore] once the buffer cast is fixed.

How to reproduce

cargo test --release -p threecrate-gpu --lib tsdf

[rajgandhi1]

Root cause found (and fixed locally).

This is not a buffer-size mismatch — the original title was wrong. It is an alignment panic:

cast_slice > TargetAlignmentGreaterAndInputNotAligned

TsdfVoxel and GpuPoint3f are both #[repr(align(16))], but wgpu::BufferView::get_mapped_range() only guarantees 8-byte alignment. Calling bytemuck::cast_slice::<u8, _>() directly on the mapped range therefore panics because the target alignment (16) exceeds the source pointer alignment (8). It reproduces on any backend, not just Windows.

Fix: copy the mapped bytes into a correctly-aligned Vec (cast_slice_mut into a pre-sized Vec<T>) instead of reinterpreting the mapped range in place. Three readback sites in threecrate-gpu/src/tsdf.rs.

With the fix, all TSDF tests pass and the #[ignore] markers are removed (GPU suite: 31 passed, 0 ignored). Closing once the PR lands.