Wait until after GPS lock hold before updating position, if we can.

[fifieldt]

After the recent patch, we hold lock for a bit before updating the position. The positions that come in after the hold are genuinely better positions
than what we've been doing before. However, they only come 20 seconds
after we've got lock.

Previously, we would update the local position as soon as we got a lock as well as at the end of the hold, since a hold was not always possible. With this patch, if the settings allow, we should skip that first local position update.

Fixes #8029

🤝 Attestations

• I have tested that my proposed changes behave as described.
• I have tested that my proposed changes do not cause any obvious regressions on the following devices:
  • Heltec (Lora32) V3
  • LilyGo T-Deck
  • LilyGo T-Beam
  • RAK WisBlock 4631
  • Seeed Studio T-1000E tracker card
  • Other (please specify below)

[fifieldt]

(untested, and some code can be optimised, back on this in a couple days)

[Copilot]

Pull Request Overview

This PR optimizes GPS position updates by implementing a smart hold mechanism that waits for better GPS data before updating the local position, based on the configured update interval. When the GPS update interval is greater than 10 seconds, the system now holds for up to 20 seconds after acquiring a GPS lock to allow for ephemeris data download, resulting in more accurate position fixes.

Key changes:

• Skip immediate position updates on GPS lock when update interval > 10 seconds
• Implement conditional hold logic based on GPS update interval settings
• Restructure GPS state machine logic with clearer documentation

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

Pull Request Overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}