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.