Guard remaining level_colliders lookups against missing keys (extends #1396)

[ElBamboo]

Title

Guard remaining level_colliders lookups against missing keys (extends ryanhcode#1396)

Description

This builds on ryanhcode#1396 (@mynameisgrass / "ssarg"), which fixed the non-unwinding
panic on the rigid_bodies registry — the reported getPose crash where a
sub-level's rigid body handle could be missing after an unload. That PR is a
correct fix as far as it goes, but there is a second, separate registry,
level_colliders, that was left entirely unguarded. It's indexed by the same
kind of Java-supplied id, on the same kind of "the sub-level may have been
unloaded between the Java call and this native call" race, and it panics the
same way: a panic!/unwrap()/expect() inside an extern "system" JNI
function is a non-unwinding panic in this build configuration, which means it
aborts the whole process (SIGABRT), not just the calling thread.

We hit this in production immediately after deploying ryanhcode#1396's fix on a
NeoForge 1.21.1 dedicated server: the original getPose panic disappeared,
and was immediately replaced by this one, one call further down the same
code path (onStatsChanged calls setCenterOfMass then setLocalBounds
back to back):

thread '<unnamed>' panicked at rapier/src/lib.rs:557:14:
called `Option::unwrap()` on a `None` value
thread caused non-unwinding panic. aborting.
   ...
Java_dev_ryanhcode_sable_physics_impl_rapier_Rapier3D_setCenterOfMass

What this does

Audited every JNI entry point that reads or writes level_colliders (or a
rigid_bodies handle resolved indirectly through it) by an id coming from
Java, and replaced unwrap() / expect() / direct map indexing with
Option-based guards, following the same pattern ryanhcode#1396 used for
rigid_bodies. Where the guarded value only feeds a performance heuristic or
a cosmetic detail (see below), the fallback is the pre-existing default
rather than skipping the whole call, since correctness doesn't require it.

Sites fixed (none touched by ryanhcode#1396):

• lib.rs — setCenterOfMass, setLocalBounds, addChunk
• contraptions.rs — get_kinematic_collider_info (now returns
  Option<&mut _> instead of .expect()-ing) and its two callers;
  createKinematicContraption's mount-body lookup; removeKinematicContraption
  guarded against a double-remove
• rope.rs — tick()'s start/end attachment anchor updates, for a rope
  still attached to a sub-level that has since been unloaded
• dispatcher.rs — the collision-pair swap-order heuristic, and both
  world_vs_world contact-manifold code paths
• hooks.rs — fake-velocity lookups in both solver-contact hooks

Testing

Cross-compiled sable_rapier for x86_64-unknown-linux-gnu.2.17 (matching
the release target used for the official builds — verified via objdump,
max required symbol is GLIBC_2.17), swapped only the native library inside
sable_rapier_binaries.zip.l4z in an otherwise-untouched production jar, and
deployed to the affected server. Applying ryanhcode#1396 alone traded the getPose
panic for the setCenterOfMass panic above within the same play session
(repeated sub-level load/unload near a player). With this patch on top of
ryanhcode#1396, both crashes are gone under the same reproduction.

This has not been reviewed by a Rust engineer beyond that runtime
verification. In particular I'd like a second opinion on whether any of the
now-silent no-op paths should do more than nothing — e.g. whether a rope
whose attachment sub-level disappears mid-tick() should also get cleaned
up/detached rather than just being left with a stale anchor until the next
dead_start_attachments/dead_end_attachments sweep catches it via the
joint-handle check.

Attribution

This patch was written and applied by Claude (Anthropic) at my direction
— I described the crash, gave it FTP access to the affected server and its
logs, and asked it to find and fix the underlying cause. It read ryanhcode#1396,
found the level_colliders gap, wrote these guards, cross-compiled and
verified the fix live before I asked it to prepare this PR. I'm submitting
it because it fixed a real production crash for me and the diff looked
correct to me on review, but flagging the authorship clearly so maintainers
weight the review accordingly.

[mynameisgrass]

thanks for the fix man