bugfix(ai): Do not rebuild the locomotor set of a dead aircraft

[wh1ter0se69]

• Fixes Airplane and helicopter wrecks can become stuck circling in air #62

What happens

JetSlowDeathBehavior::beginSlowDeath() grounds a dying aircraft by mutating the current
Locomotor instance:

Locomotor *locomotor = us->getAIUpdateInterface()->getCurLocomotor();
locomotor->setMaxLift( -TheGlobalData->m_gravity * (1.0f - modData->m_fallHowFast) );
locomotor->setMaxTurnRate( 0.0f );

A dead aircraft's AI keeps running - there is no death guard in AIUpdateInterface::update() -
and when it changes locomotor set, chooseLocomotorSetExplicit() throws that instance away:

m_locomotorSet.clear();          // deleteInstance() on every Locomotor in the set
m_curLocomotor = nullptr;
for (...) m_locomotorSet.addLocomotor(lt);   // TheLocomotorStore->newLocomotor(lt)

and Locomotor::Locomotor(const LocomotorTemplate*) starts fresh:

m_maxLift = BIGNUM;
m_maxTurnRate = BIGNUM;

So the wreck silently regains full lift and full turn rate. It is no longer falling - it is a
flying aircraft with no pilot, and DestructionDelay = 99999999 means nothing removes it. It
circles until the match ends.

The fix refuses the rebuild for an effectively-dead aircraft, so the slow-death locomotor
survives and the wreck falls.

Why this file

The bug is in AIUpdateInterface, not in a slow-death module. Every aircraft reaches
chooseLocomotorSetExplicit(), which is why the issue reports jets and helicopters - Aurora,
Raptor, Chinook, Comanche, MIG, Helix. A fix in JetSlowDeathBehavior could never have covered
the helicopters.

Refinement of the 2023 hypothesis

The guess in the issue thread was "if plane dies while it changes state to return to airfield".
Right shape, wrong specific. The captured trigger was LOCOMOTORSET_SLUGGISH, reached from a
Guard order - not the return-to-airfield path. A fix targeting only that path would have
missed it.

Evidence

Measured on a VC6 Release build (RTS_BUILD_OPTION_DEBUG=OFF), with a temporary probe
logging any locomotor-set rebuild on an effectively-dead aircraft.

Reproduction, captured live (USA Superweapon, Auroras guarded then killed airborne):

[GXWRECK] frame=18807 obj=612 tmpl=SupW_AmericaJetAurora newset=7 hadLoco=1 airborne=1

newset=7 is LOCOMOTORSET_SLUGGISH; hadLoco=1 confirms the slow-death locomotor was present
and was about to be discarded; airborne=1 confirms it was still in the air.

A/B on that recording, same binary, fix toggled by env var so playback is identical up to the
first block:

	events	outcome
fix off	1 rebuild allowed	stays airborne=1, circles indefinitely
fix on	87 rebuilds refused	airborne=0 at frame 18894 - falls in ~3 seconds

The CRC mismatch that follows in the fixed run is expected: the wreck now hits the ground, so the
simulation legitimately diverges from a recording of the broken behaviour.

No regression, against the full GeneralsReplays/GeneralsZH/1.04 CI corpus - 10 replays,
roughly four hours of game time:

	replays completed	CRC errors	wall clock
before	10/10	0	8:23
after	10/10	0	8:25

Both passes produced byte-identical stdout. The replay corpus still passes with this fix
enabled, so it does not need to be gated behind a retail-compatibility macro - the guard only
engages on an already-dead aircraft, a state the corpus never reaches.

Known limits

Stated plainly rather than left for review to find:

• The corpus survey found zero instances of the trigger, so "affects all aircraft" is a claim
  from code structure - both the bug and the fix are in code every aircraft executes - not from
  measuring each aircraft. Only the Aurora path was reproduced end to end.
• JetAIUpdate calls setMaxLift() directly in several places for landing/takeoff sequencing.
  Those bypass the locomotor set change entirely, so this fix does not intercept them. Whether
  they are reachable on a dead jet is not established here.
• With the fix in place the AI retries the refused set change every frame (87 times in the
  capture above). Harmless and cheap, but it indicates the state machine is spinning on a
  transition it can never complete. A broader fix - not driving a dead aircraft's AI at all -
  may be the better long-term shape, and is a bigger behavioural change than this one.