Repository: godot
Issue: `MeshInstance3D`'s auto-initialized `skeleton` property leads to confusing errors when no skeleton is desired
Labels: bug,topic:animation,topic:3d

### Tested versions

Reproducible in 4.3.stable and 4.4.dev7

### System information

Godot v4.3.stable - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1660 SUPER (NVIDIA; 32.0.15.6636) - Intel(R) Core(TM) i7-10700F CPU @ 2.90GHz (16 Threads)

### Issue description

`MeshInstance3D` automatically and silently assigns its initial parent node as its "skeleton". This happens regardless if the parent is actually a `Skeleton3D` instance, and regardless if a skeleton is even desired (in the vast majority of use cases, it is not). If the user rearranges the `MeshInstance3D` in the edited scene as part of normal editing operations, it will silently retain this initial presumed "skeleton" reference.

At runtime, if the `MeshInstance3D` is added to the scene tree and its presumed "skeleton" is not found at the same relative path, it will throw an error, which is extremely confusing for any user who never used a skeleton in the first place, and never explicitly assigned the node reference. It does not help that the error does not mention the presumed `skeleton` reference as being the source of the issue either:
```
E 0:00:02:0081   test.gd:23 @ _show_statue(): Node not found: "../../statue1" (relative to "/root/test/statue2/figure2").
```
Another confusing error is thrown in the editor itself if the presumed "skeleton" is deleted:
```
core/string/node_path.cpp:263 - Condition "!p_np.is_absolute()" is true. Returning: NodePath()
```
And an even more confusing one is thrown if it is restored with undo:
```
Node not found: "../../statue1" (relative to "/root/@EditorNode@16886/@Panel@13/@VBoxContainer@14/DockHSplitLeftL/DockHSplitLeftR/DockHSplitMain/@VBoxContainer@25/DockVSplitCenter/@VSplitContainer@52/@VBoxContainer@53/@PanelContainer@98/MainScreen/@CanvasItemEditor@9272/@VSplitContainer@9094/@HSplitContainer@9096/@HSplitContainer@9098/@Control@9099/@SubViewportContainer@9100/@SubViewport@9101/test/statue2/figure2").
```

I'm sure there's some systemic reason for this automatic caching of a presumed "skeleton", but the results are undesirable for the majority. It is also strange that the manual selection UI for the property _prohibits_ the user from selecting non-`Skeleton3D` nodes. So why does the auto-caching code do this?

### Steps to reproduce

- Open the attached project/scene.
- Context: the `figure` nodes under `statue2` and `statue3` were created by duplicating the one under `statue1`. As such, they erroneously retained `statue1` as their "skeleton", despite now being placed in their own statues.
- Delete `statue1`. Note the error that appears in the `Output` tab.
- Restore `statue1` with undo. Note the error that appears in the `Output` tab.
- Run the project.
- Click the "Cycle Statues" button. This will remove a statue from the scene and add the next one.
- Note the error that appears when `statue2` or `statue3` are shown. This is because `statue2/figure` and `statue3/figure` are looking for `statue1` as their "skeleton", but `statue1` has been removed from the scene, so it cannot be found.

![Image](https://github.com/user-attachments/assets/bac3c843-bf73-4610-b1ac-392b8f5d1ba4)

### Minimal reproduction project (MRP)

[bug-report.zip](https://github.com/user-attachments/files/18326755/bug-report.zip)