Fix lock-position crosshair jump when guiding starts

[Eyeke2]

Summary

This PR fixes a long-standing and annoying PHD2 guiding issue:
when starting guiding from a state that already had a lock position
(e.g. after a previous guiding session or after AutoSelect/click), the
calibration crosshair was drawn at the stale lock from the previous
cycle and then visibly snapped to the new lock at the moment
STATE_GUIDING was entered.

With this change, the displayed lock/crosshair position is kept consistent
with the newly selected guide position from the start of the guiding transition,
avoiding the misleading stale crosshair and the visible snap.

Root cause

Guider::SetState STATE_GUIDING entry block unconditionally
overwrote a valid lock with CurrentPosition() (unless sticky was
set), which is what produced the jump. Meanwhile, nothing refreshed
the lock at the start of the calibration cycle, so the crosshair
was drawn at the stale previous-session value throughout calibration.

Fix

Two paired edits in src/guider.cpp:

1. At STATE_CALIBRATING_PRIMARY entry, anchor the lock on the
   current star (skipping when sticky is set and the lock is already
   valid). The calibration crosshair is now drawn at the correct
   guiding target from the first frame.

2. At STATE_GUIDING entry, stop overwriting a valid lock with
   CurrentPosition(). Only fall back to CurrentPosition() if the
   lock is somehow missing.

Net effect: the lock is established once, at the start of the cycle,
and stays static through calibration and guiding (except via the
existing lock-shift mechanism). No visible snap.

Behavior preserved

• Sticky lock: unchanged - the calibration-entry check keeps a valid
  sticky lock in place, and the guiding-entry fallback never fires.
• Lock-shift (comet): unchanged - ShiftLockPosition() runs in
  UpdateGuideState, not at state-entry.
• Already-calibrated mounts (skipped calibration): the
  STATE_CALIBRATING_PRIMARY case still executes the anchor before
  falling through, so the lock is set in that path too.
• Defensive fallback at STATE_GUIDING entry covers any path that
  arrives without a valid lock.

Notification side-effect

EvtServer.NotifySetLockPosition fires once per cycle (at calibration
entry, only when the value differs from the previous lock) instead of
at guiding entry. No increase in notification rate.

Testing

• Start session, calibrate, guide, stop. Slew elsewhere. AutoSelect or
  click a new star. Click Guide.
  • Before: yellow dotted crosshair appears at the old session's lock
    during calibration, then snaps to the new star at GUIDING entry.
  • After: crosshair appears at the new star from the first calibration
    frame and does not move.
• Sticky lock workflow (Drift tool, PhdController useStickyLock):
  lock stays where the user/controller set it.
• Lock-shift enabled: lock continues to drift normally during guiding.

[bwdev01]

I have only looked at this briefly but I doubt that you can eliminate the call on SetLockPosition() at the start of guiding. You can't assume calibration has just been done, that will nearly always be false. Here's a quick test for the simulator:

1. Start looping with an already calibrated profile. Auto-select a start and note the position of the cross-hairs
2. Use the manual guide tool to displace the image by a significant number of pixels
3. Click on the guide button. I think you will see the cross-hairs are not positioned on the star and there will initially be wild guiding behavior - all of this is without sticky lock positions, of course.

I think we need to be extremely careful here. The problem you're addressing - which I can see - is essentially cosmetic and in fact has gone unnoticed for years and years. But the guiding behavior is completely accurate. I wouldn't want to see us jeopardize the latter for the former. :-) As I said, I've only looked at this briefly, so forgive me if I'm mistaken.

[Eyeke2]

Thanks, Bruce. I repeated the simulator test, and I think my initial interpretation of the result was mistaken.

In this scenario, I now see the same final lock-position behavior both before and after the PR: when guiding starts, the current/latest star position is used as the lock position. The difference is that unmodified PHD2 shows a visible jump of the crosshairs from the originally selected star position to the latest star position, whereas with this PR the crosshairs are already updated consistently, so no jump is visible.

Regarding the behavior you were concerned about, I do not currently see the PR changing the final lock position or causing it to remain at the original auto-selected location. It appears to preserve the existing guiding behavior while eliminating the misleading visual jump.

That said, your test was very useful because it highlights a related behavioral question: should the original user-selected or auto-selected position remain the lock target if the star drifts before guiding starts, or should PHD2 continue using the latest star position, as it does today? I may experiment with that separately in my solar branch, but I agree that this would be a distinct behavior change and should not be conflated with this PR.

For this PR, my intent is narrower: to preserve the existing final lock-position behavior while keeping the displayed crosshairs consistent during the transition into guiding.

I’d appreciate it if someone else could also test this PR.

[bwdev01]

My objection at this point is the elimination of the SetLockPosition call at the start of guiding. The undocumented rule is that unless you are using a sticky lock position, then the start of any guiding sequence will set the lock position to the current primary star position. This has the effect of starting at a zero-point and avoiding big guiding corrections, multi-star stabilization periods, and long settling times at the start of the guiding sequence. By not using a sticky lock position, you have basically said this convention is desirable. Coming back to the unexpected UI behavior for calibration, I don't have a problem with trying to fix that but it shouldn't have any effect on how the start of guiding behaves. I'll point out that if best practices are being followed and calibrations are being done by the Calibration Assistant, the UI behavior won't be seen. Similarly, if calibrations are being done only once at the start of the night, the behavior is very unlikely to be seen. These are the normal use cases because ST-4 style guiding and repetitive calibrations are a rarity these days. So if you can revert the changes you made regarding the start-of-guiding state, there should still be a way to eliminate the UI behavior in calibration that is bothering you.