fix: stuck GNSS control logic on intermittent data

[bresch]

Solved Problem

I found a race condition where the GNSS checks initially passed and then started to fail intermittently while the drone was on the ground (no relaxed checks). This caused the GnssChecks::run function to always return false, which prevents the samples to be fused, but the GNSS fusion never gets disabled as _time_last_pass_us is still updated by the intermittent good samples.
This logic is supposed to stop the GNSS fusion when quality is degraded.

Solution

Only update _time_last_pass_us when the full check really passes (includes the hysteresis).

Test coverage

add unit test to re-create the race condition (fails without the fix)

[github-actions]

❌ PR title needs conventional commit format

Expected format: type(scope): description (conventional commits).

Your title:

fix: stuck GNSS control logic on intermittent data

Suggested fix:

feat(fix): stuck GNSS control logic on intermittent data

To fix this: click the ✏️ next to the PR title at the top of this page and update it.

See CONTRIBUTING.md for details.

---

This comment will be automatically removed once the issue is resolved.

[github-actions]

💡 Commit messages could be improved

Not blocking, but these commit messages could use some cleanup.

Commit	Message	Suggestion
c8512bdc64	test: add intermittent GNSS failure case test	Missing conventional commit format (e.g. "feat(ekf2): add something")
28f7bb5eb4	fix: only record GNSS check success time when passing hysteresis	Missing conventional commit format (e.g. "feat(ekf2): add something")

See the commit message convention for details.

---

This comment will be automatically removed once the issues are resolved.

[haumarco]

can you use the type(scope): description format for the commits to make CI happy