Handle collision shape failures during collider baking

[MACTEP-ABATAP]

Summary

Makes Rapier collider baking more defensive when retrieving block collision shapes. Some blocks, especially from mods with complex or multiblock collision logic, may throw while Sable is building physics collider data. Without this, a single bad collision shape can crash collider baking and may leave the temporary block getter state configured for the failed block.

After this PR, collision shape retrieval failures fall back to an empty shape instead of crashing, and the temporary block getter state is always reset after retrieval.

The problem

RapierVoxelColliderBakery temporarily configures PhysicsColliderBlockGetter with the block state being baked, then asks the block for its collision shape.

Previously, if either path threw:

• BlockSubLevelCollisionShape#getSubLevelCollisionShape
• BlockState#getCollisionShape

then this.level.setup(Blocks.AIR.defaultBlockState()) would not run. That could leave the shared block getter in a stale state and crash the caller.

A mod returning null for a collision shape would also fail later at shape.isEmpty().

Changes

• Wrap collision shape retrieval in defensive error handling.
• Move this.level.setup(childState) into the guarded block.
• Reset the temporary block getter state in a finally block.
• Fall back to Shapes.empty() when shape retrieval fails.
• Treat null collision shapes the same as empty collision shapes.
• Keep the existing collider behavior unchanged for valid blocks and liquids.

Testing

Not run in-game yet.

Recommended checks:

• Start a world with the modpack that previously crashed during collider baking.
• Verify the server no longer crashes when the problematic block is encountered.
• Verify normal solid blocks, liquids, fences, and walls still produce expected Rapier collision data.
• Check logs for the new warning output when a problematic block falls back to an empty collision shape.

Notes for reviewers

This change intentionally prefers a safe empty collider over crashing. That means a problematic block may temporarily behave as non-solid for Rapier physics, but the game/server remains alive.

The finally block is the important part of the change: even when a mod throws while building a collision shape, PhysicsColliderBlockGetter is reset back to air before the method returns or continues.

Known limitations

• A block whose collision shape retrieval fails will be treated as empty collision data.
• Because collider data is memoized per BlockState, a fallback result may stay cached for that bakery instance.
• The current implementation logs to System.err; this can be replaced with the project logger later if preferred.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[MACTEP-ABATAP]

Potentially closes #1328

[superintendent2521]

would it not be better to build a generic block collision hitbox so you still have collisons, depsite the fact that they might not be accurate to the model

[MACTEP-ABATAP]

Changes

• Wrap collision shape retrieval in defensive error handling.
• Move collision shape retrieval into getCollisionShapeOrFallback.
• Reset the temporary block getter state in a finally block.
• Fall back to Shapes.block() when shape retrieval fails.
• Treat null collision shapes as full block collision shapes.
• Use Sable.LOGGER.warn instead of writing directly to System.err.
• Keep the existing collider behavior unchanged for valid blocks and liquids.

Testing

• Run ./gradlew :sable_rapier:compileJava --stacktrace.
• Built test jars with ./gradlew :fabric:remapJar :neoforge:jar.

Recommended in-game checks:

• Verify problematic blocks still have a generic full-block Rapier collider.
• Verify normal solid blocks, liquids, fences, and walls still produce expected Rapier collision data.
• Check logs for the new warning output when a problematic block falls back to a full block collision shape.

Notes for reviewers

This change intentionally prefers a generic full-block collider over either crashing or treating the block as non-solid. The fallback may not perfectly match the block model, but it preserves collision behavior well enough for problematic modded blocks.

The finally block is still the important safety piece: even when a mod throws while building a collision shape, PhysicsColliderBlockGetter is reset back to air before the method returns or continues.

Known limitations

• A block whose collision shape retrieval fails will be treated as full block collision data.
• Because collider data is memoized per BlockState, a fallback result may stay cached for that bakery instance.