Guard Havok world objects against release while their world holds them

[viktor-ferenczi]

Ports the Havok world-object dispose guard out of the Remote plugin (SE1-0009), as a Shared patch so the client and the dedicated server both get it.

The bug

HkHandle releases its native object both from Dispose() and from its finalizer, and HkWorld keeps no managed reference to the phantoms added to it. A rigid body or phantom whose managed wrapper is dropped without a RemoveRigidBody/RemovePhantom is therefore released while the broadphase still holds it, and the next broadphase pass walks freed memory.

Nothing about that is platform specific — it is managed lifetime handling, present on Windows, and the DS steps the same worlds through the same wrapper — so it belongs here rather than in linux-compat or in a test-harness plugin.

The fix

• An explicit Dispose() of a world object removes it from its world first, then lets the release proceed.
• The finalizer of one skips the native release entirely. A leak is far cheaper than a freed body in the broadphase, and the finalizer thread must not touch the world.
• AddPhantom/RemovePhantom keep a native pointer -> world map, because phantoms are not entities and have no world pointer to read back. A disposed HkWorld drops its entries, which would otherwise outlive it and match whatever allocation reuses the pointer.

Two deliberate changes over the version that lived in Remote: the explicit-dispose path can now actually skip the release it claims to skip (Remote's void prefix discarded that decision and freed the body anyway), and the world-dispose purge above is new.

The patches are applied one at a time after PatchAll rather than by it, each in its own try/catch and every target named with an explicit argument list. HkHandle has both Dispose() and Dispose(bool), and an ambiguous target there aborts the whole PatchAll — in Remote that once took every patch in the plugin down at once. A bugfix must not be able to disable its siblings.

Testing

Verified on both arms, armed and silent:

• Dedicated server (Magnetar, Earth world, no clients): ~9 min including a shutdown-with-save. All four targets resolve against the DS assemblies.
• Client (headless Pulsar): world load, three ships closed, ~7000 frames at sim speed 1.0, then a full session reload.

The repair logic itself is untested. Every run above took the early-return path, so none of the four remedial branches has ever executed. The guard has not been observed to fire since the MXCSR FTZ/DAZ fix in the PE loader resolved T-0068's root cause, and there is no instrumented fleet left to campaign — so this goes in as a fix that is correct by inspection, not one with a reproduction behind it. If a campaign on the current wrapper leaves the counts at zero, deleting it is still the right call.