Fix TelescopeSimulator IsSlewing/AtPark wedging (slew-state thread-safety + GEM hour-angle-limit crossing)

[ivonnyssen]

Summary

TelescopeSimulator can leave IsSlewing (and, relatedly, AtPark) stuck true forever, so a client that polls after a SlewToCoordinates/Park waits until its own timeout. There are two independent causes, fixed in the two commits here. Both are in TelescopeSimulator/TelescopeHardware.cs; no public behaviour changes and no ConformU regressions.

Cause 1 — unsynchronized shared slew state (thread races)

TelescopeHardware shares its slew state (mountAxes, targetAxes, slewing, SlewState, currentRaDec, AtPark) between the Kestrel HTTP request threads (StartSlewAxes / SyncTo* / AbortSlew / the Slewing/RA/Dec/AtPark accessors) and the s_wTimer tick thread (MoveAxes → DoSlew), with no synchronization.

• StartSlewAxes' writes aren't ordered against the timer thread's reads, so on weak memory (AArch64) or under JIT register caching the tick can observe SlewState == SlewRaDec while still seeing slewing == false. DoSlew bails, MoveAxes' tail switch has no SlewRaDec case, and the slew never advances — IsSlewing stays true indefinitely.
• The same race on the unsynchronized AtPark accessor lets a client polling AtPark after Park() miss the tick's park-completion write and spin until its deadline.
• Init() (run on every Telescope (re)construction) allocated a fresh AutoReset System.Timers.Timer each call without stopping/disposing the previous one, so each reconstruction leaked a live tick source firing M_wTimer_Tick on the shared static state. It also reset the slew-engine state outside any lock and never cleared slewing.

Fix (77a32a2): introduce one hardwareLock, taken on both sides — the timer tick, StartSlewAxes, AbortSlew, SyncToTarget, SyncToAltAzm, and the IsSlewing / RightAscension / Declination / AtPark / SlewState accessors (Monitor is reentrant, so the tick writing while holding the lock is safe). In Init(), stop/unsubscribe/Dispose the existing timer before allocating a new one, and reset the slew-engine state (incl. slewing = false) under the lock.

Cause 2 — GEM goto crossing the hour-angle limit

On a German equatorial mount, DoSlew rotates the primary axis the shortest way (delta wrapped to (-180, 180]). When a goto's target sits ~180° away in axis space — e.g. a sync onto one pier side followed by a slew whose natural side is the other — that shortest rotation can drive the primary axis through the hour-angle software limit (180 + hourAngleLimit). CheckAxisLimits then undoes the move every 100 ms tick, so finished is never reached, slewing stays true, and IsSlewing is stuck true forever.

Fix (bfb473e):

• In DoSlew, when the shortest-path primary rotation would leave the GEM mechanical range [-hourAngleLimit, 180 + hourAngleLimit] but the same target is reachable the other way round, take the longer rotation. It reaches the identical target axes, so the pier side is unchanged (no SideOfPier/conformance impact), and it's a no-op for any slew whose short path stays in range.
• Add a no-progress guard in MoveAxes: a slew making < slewSpeedSlow/2 progress for 0.5 s is stopped (Slewing → false) instead of reporting IsSlewing forever — a backstop for genuinely unreachable targets. Tracking drift (~0.0004°/tick) is far below the threshold, so healthy slews never trip it.

Verification

• ConformU telescope conformance passes, including SideOfPier Write OK; the no-progress guard never fires in normal operation.
• The former-wedge geometry now converges (~10 s to target, on the natural pier side) instead of hanging.
• These fixes have been running in a downstream fork build for several weeks against automated Alpaca integration tests with no recurrence of the hang.

Scope / risk

• Single file (TelescopeSimulator/TelescopeHardware.cs), +196/−33, comments included.
• No public API or behaviour changes; the locking is additive and the GEM change preserves the resolved target (and therefore pier side).