Landed state when creating air unit causes the unit to become stuck

Air units built on top of air plants spawn in a "landed" move state that can cause them to attempt to land on the terrain beneath the factory instead of obeying their first Move/Build/etc orders. \[See investigation by KAS, below, on what causes this.\]

Multiple problem scenarios that seem to be caused by this one behavior:

- Whether the unit attempts to land or to move depends (somehow) on the distance to their first order. \[I'd isolated this distance to the air unit's turn radius in its movetype data.\]
- When the unit is not collideable, it sinks through its factory to reach the ground, rather than taking off up/sideways.
- When the unit is collideable, then it becomes stuck that way.
- If the factory is not blocked off from building, then multiple collideable air units stack on top of one another.
- See: https://github.com/beyond-all-reason/Beyond-All-Reason/issues/6325

Request is to poke a "landed" unit with orders on creation in a more elegant way.

We looked at our current workarounds:

- Send duplicate Wait orders: https://github.com/beyond-all-reason/Beyond-All-Reason/pull/6574
- Set an achievable move goal: https://github.com/beyond-all-reason/Beyond-All-Reason/pull/5615

And found that these are unwanted solutions.

The issue does not name files, tests, or entry points. Start by reproducing creation of an air unit from an air plant with an immediate Move or Build order, then trace the creation and initial movement-state handling; done means the unit leaves the landed state and obeys its first order without sinking, landing on terrain, or stacking with later units.

Written by the indexing model from the issue text.