ClosestBuildPos seems to ignore LOS by default, both in synced and unsynced cases

https://github.com/beyond-all-reason/RecoilEngine/blob/37e13b5986ca547376ee111347e792d6a910f4c9/rts/Game/GameHelper.cpp#L1092

Might consider adding an optional "confirmInLOS" arg,
> default false in synced, but giving the option to take LOS into consideration (using the provided teamID for reference)
> always true in unsynced, disabling any form of LOS hack through using that function

From reading code; it seems unlikely that TestUnitBuildSquare() would fail, as it does have an inLOS check.
I'm wondering if possibly, the addition of a secondary (broader) check for any immobile unit is what's failing and causing a position to be discarded: https://github.com/beyond-all-reason/RecoilEngine/blob/37e13b5986ca547376ee111347e792d6a910f4c9/rts/Game/GameHelper.cpp#L1142-L1183

To confirm that, i tried echoing TestBuildOrder results and check wether or not ClosestBuildPos (with 0 min dist) is returning the same pos when TestBuildOrder returns 2.
Despite the build pos being tested as unblocked, closestbuildpos still moves the build pos somewhere else.

Start with the linked sections of rts/Game/GameHelper.cpp, especially ClosestBuildPos around line 1092 and the immobile-unit check around lines 1142–1183; compare their behavior with TestBuildOrder and TestUnitBuildSquare. Done means the reported case is understood and ClosestBuildPos handles LOS as described for synced and unsynced calls.

Written by the indexing model from the issue text.