[Bromeon]

In CI workflow runs A, B and C, job godot-itest (linux-features-experimental) failed with a process abort (core dump). The Godot process printed:

thread caused non-unwinding panic. aborting.

...but without any panic payload. It turned out to be a latent race condition in godot-rust; I could reproduce it on Godot version fa6cad230. Running tests filtered by [async,signal_] on two cores (taskset -c 0,1) let the abort appear in ~1/76 runs.

When a SignalFuture is dropped, FallibleSignalFuture::drop disconnects its ONE_SHOT resolver via Signal::object(). If the signal's object is freed concurrently on another thread, that access panics -- and a panic inside Drop becomes a non-unwinding abort.

This was only reachable through unsafe, since Gd is !Send and must be bypassed to free it on another thread. In our case it's the ThreadCrosser.

---

This PR applies multiple fixes and hardenings:

1. Skip cleanup when nothing needs disconnecting. drop only touches the object while the future is still Pending; once the signal fired, the ONE_SHOT connection is already gone. This eliminates the reproduced abort.
2. Fix Signal::object() not properly catching dead objects. We now use is_instance_valid() on the object returned by Godot's own Signal::get_object API and return None for dead objects, instead of panicking (which could happen in Drop).
3. Contain remaining panics in Drop. For the rare Pending-and-freed-concurrently TOCTOU race, cleanup is wrapped in handle_panic. Instead of aborting, we skip the disconnect() and leave the connection registered. Godot will disconnect all object's signal connections when the object is destroyed, releasing the reference it holds to our resolver Callable.

[GodotRust]

API docs are being generated and will be shortly available at: https://godot-rust.github.io/docs/gdext/pr-1617