Repository: godot
Issue: ShapeCast3D has massive accuracy issues
Labels: topic:physics,needs testing,topic:3d

### Godot version

v4.1.1.stable.official [bd6af8e0e]

### System information

Godot v4.1.1.stable - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3050 Laptop GPU (NVIDIA; 31.0.15.4617) - 12th Gen Intel(R) Core(TM) i5-12500H (16 Threads)

### Issue description

A ShapeCast3D with a sphere shape set is varying its collision distance from another collider wildly when moving a few units parallel to its extend direction. This problem does not show itself with RayCast3D.

![Godot_v4 1 1-stable_win64_Mgu49AgIm7](https://github.com/godotengine/godot/assets/74799857/140ee28a-69d5-4191-9aa5-7a7a8e99cac9)

#### How I expect it to work
Cast a shape downwards, onto a collider like a CSGBox, and the shapecast cast will stay at one Y level.
Move the shapecast origin in the X and Z axis, and the Y level of the cast should stay the same.
#### How it actually performs
Move the shapecast origin in the X and Z axis, and the Y level of the cast _changes_.
Using debug shapes, the sphere shape visibly bounces, even though the origin's height stays the same.
Variations of >0.0001 aren't great for physics sims, but I can see variations of >0.1, which are unacceptable!

#### My observations:
StaticBodies from meshes do not show this problem if the shapecast hits the front-side of a tri, but do show if the shapecast hits the back-side of a tri.
CSGBoxes with large sizes show this problem very often, as an user tends to make one single large csgbox instead of one for each cubic meter of space.

This behavior would usually not occur in Godot-JoltPhysics, but if I use a CSGBox with _flipped faces_ there, it does.
My guess is that sphere ShapeCasts don't go well with reversed normals, yet CSGBoxes have double-sided faces with the back-side interfering with the front-side from lack of accuracy?

I think the distance from the sides of a tri increases the effect, so casting to the center of a tri has more visible effects than casting closer to that tri's edge, but I'm not sure.

#### Why is it a problem
For physics simulations like vehicles, any minor deviations can cause major instability in suspension and wheel systems.
For clipped cameras, camera positions jerking when in contact with walls and ceilings may lead to motion sickness.
This makes CSG objects unusable for prototyping with those systems in mind, requiring a blender-first workflow to ensure no back-face or double-face colliders, which is not ideal.

### Steps to reproduce

1. Make a new ShapeCast3D, set shape to Sphere.
2. Make a new CSGBox, and set the X and Z size to a large value, like 1000.
3. Check the CSGBox's _use collision_ bool.
4. Set some way to move either the shapecast or the box, like a Path or a KinematicBody or simple keyboard controls.
5. Move the two so that the shapecast collides with the box. Check the height of the cast (with DebugShapes or printing to the console)
6. Keep moving the objects, while keeping the Y positions of both the same. Check the height of the cast again.

### Minimal reproduction project

[ShapecastAccuracyBug.zip](https://github.com/godotengine/godot/files/13460673/ShapecastAccuracyBug.zip)
There's a ``test_shapecast`` scene with a csgbox and a shapecast tied to a path, as seen in the example gif.
There's also a ``test_shapecast_on_mesh`` scene with two square planes from Blender set up as static bodies, and one's upside down, as well as the raycast and the path.