Boneless docks lose their caller-directed approach bias after a load

[bobtista]

A structure with no docking bones stops steering arrivals toward the side they approach from once a save is loaded. Dockers are all sent to the same spot at the structure centre instead of fanning out, so they queue up and take longer routes, or fail to find one.

DockUpdate::computeApproachPosition biases the approach point toward the caller only when the structure has no waiting bones:

if( m_numberApproachPositionBones == 0 )
{
    // A Boneless building wants to bias towards the caller for the arbitrary position
    ...
}

m_numberApproachPositionBones is not written to the save. It starts at -1 in the constructor and is only assigned inside loadDockPositions():

https://github.com/TheSuperHackers/GeneralsGameCode/blob/main/GeneralsMD/Code/GameEngine/Source/GameLogic/Object/Update/DockUpdate/DockUpdate.cpp#L520-L537

Every call to loadDockPositions() is guarded by if( m_positionsLoaded == FALSE ), and m_positionsLoaded is saved. So on load the guard is already satisfied, the count is never recomputed, and it stays at -1 for the life of the object. -1 is not 0, so the boneless branch never runs again.

This affects any structure that reports zero waiting bones: one with no DockWaiting bones, a KINDOF_IGNORE_DOCKING_BONES structure such as the fortified GLA Supply Stash, and every dynamic approach dock, which is forced to zero bones.

Repro:

1. Have a docker approach a structure with no docking bones, so its positions are loaded
2. Save
3. Load that save
4. Send more dockers to it

They are routed to the structure centre rather than biased toward their own approach side.

Measured with a probe on the count, saving on the frame a dock finishes loading its positions, with the loaded flag as a control:

	saved	loaded
approach position bone count	0	-1
positions loaded flag (control)	1	1

The loaded flag survives, which is also the mechanism: it is what stops the count being recomputed.

The same xfer body is in Generals.