MeshToSDFBaker writes out of bounds past the triangleIDs buffer when a mesh exceeds the triangle list size estimate

Steps to reproduce:
1. Open the attached user's project "IN-150840_SdfBakerOobRepro.zip"
2. Download the "SdfBakerRepro.cs" script and attach it to "GameObject" in the Hierarchy (Remove "SdfBakerOobRepro" component)
3. Set the "Mode" of the attached component to "Defect 3 only"
4. Set Player Settings > Other Settings > Graphics APIs for Windows to Vulkan only
5. Build a Windows standalone Player (Development Build)
6. In Vulkan Configurator, enable "Configure System Vulkan Layers", select the Validation configuration and enable GPU Assisted Validation (GPU Dump off, Safe Mode and "Force on robustness features" off)
7. Run the built Player
8. Search "Player.log" for "06936"

Actual result: "access out of bounds" validation errors (VUID-vkCmdDraw-storageBuffers-06936) are thrown from Hidden/VoxelizeShader while writing the triangleIDs buffer
Expected result: No validation errors are thrown during the bake

Reproducible with: 6000.0.83f1, 6000.3.24f1, 6000.6.0f1, 6000.7.0a6

Testing Environment: Windows 11
Not reproducible on: no other environment tested

Notes:
-Not reproducible in the Editor
-Cause: in Shaders/SDFBaker/RayMapVoxelize.shader pass 2, the three "triangleIDs[indexTri] = input.triangleID;" stores have no capacity check, where indexTri comes from "InterlockedAdd(counter[id3(coord)], 1, indexTri)"
-m_TrianglesInVoxels is allocated at MeshToSDFBaker.cs:933 from the heuristic at lines 771-773: max(nTriangles * 30, maxResolution^2 * sqrt(nTriangles)), capped at 1536 << 18
-The repro deliberately sets the bake box to 1.1 against a 1.0 cube so no geometry reaches the far plane. This suppresses the separate unclamped-depth-coordinate defect, which otherwise produces an undefined indexTri from an out-of-bounds atomic and causes triangleIDs writes that look like this one but are not
-Suggested fix: guard the three stores with the buffer capacity, matching the readers' existing clamp. Dropping overflow entries is the behaviour D3D11 users have always silently had. The reporter noted GetDimensions() does not compile on Metal, so the capacity should be passed in from C# rather than queried in the shader