Fix crash when freeing a vehicle model while its detached parts exist

[TheCrazy17]

Summary

Fixes a client crash (access violation in CVehicleModelInfo::SetVehicleColour, offset 0x000C84D8) when a custom vehicle model allocated with engineRequestModel is freed after the vehicle exploded.

Detached car parts spawned by CAutomobile::SpawnFlyingComponent (doors, bonnet, etc. flying off an exploding vehicle) are temporary game objects that store the model index of the vehicle they came from (CObject::m_nRefModelIndex + the bChangesVehColor flag), so CObject::Render can repaint them with that vehicle's colours and CObject's destructor can release its model reference. These parts outlive the vehicle element, so deallocating the model while they existed made both paths dereference the freed model info.

The fix clears those references from the game's object pool when a vehicle model info is deallocated (CModelInfoSA::DeallocateModel), the same way the game marks parts without a source vehicle (-1). It also names the two CObjectSAInterface fields involved, verified against the documented CObject layout.

Motivation

Fixes #4911

Test plan

Using the script from the issue (explode → destroy → engineFreeModel), which crashed reliably before:

• No crash when the model is freed while parts are still flying, nor when freeing before destroyElement.
• No crash when the parts despawn naturally afterwards (destructor path).
• Variants tested: freeing immediately after blowVehicle, several vehicles sharing the same custom model exploded at once, and re-allocating the same model ID after freeing it.
• Parts of vehicles with standard models still get repainted with the vehicle's colours as usual.

Checklist

• Your code should follow the coding guidelines.
• Smaller pull requests are easier to review. If your pull request is beefy, your pull request should be reviewable commit-by-commit.