fix: replace incremental comet update with full reinit

[mrosseel]

Summary

• The incremental update path in do_timed_task() could never add new comets or remove stale ones once the catalog was initially populated
• Combined with a boot-time race condition (wrong datetime before GPS lock), the initial catalog could contain wrong comets with no way to self-correct
• Fix: always call init_comets() which is already idempotent and has identical computation cost (since calc_comets() was called on every update anyway)

Symptoms observed

• 114P/Wiseman showing at mag ~14 when it should be mag 19.8
• Missing bright comets like C/2024 E1 (Wierzchos) at mag 7.6
• Only 4 comets shown instead of 11

Test plan

• Verify comet catalog initializes correctly on boot
• Verify comets update correctly after GPS lock
• Verify new comets appear and stale ones are removed on periodic update

🤖 Generated with Claude Code

[jscheidtmann]

Does this in any way depend on OS clock being synchronized to GPS clock? AFAIK, we do not have the OS clock synchronized at all! On my PiFinders I usually install Chrony and enable synchronization, but I can‘t find an indication in brickbots/PiFinder that we are trying to (synchronize OS time).

[mrosseel]

it depends on 'dt = self.shared_state.datetime()' which is set by the GPS (i think), os time is not used really. We could sync it but then we could have weird time jumps, not sure raspbian likes that. Any experiences there? Only upside is correct log file timestamps I guess.