fix(monitor): fetch radar image only on change, not every poll

[jacaudi]

Summary

processStation was calling the image source on every CheckInterval tick, regardless of whether the radar data had changed. The fetched image was then discarded for all polls except the ones that triggered a notification (first run, or VCP change). At the 5 min default that absorbed ~12 wasted renderer calls per station per hour.

Move fetchRadarImage into the two paths that actually need an image:

• First run — startup notification always carries an image so the user has visual context the moment the monitor comes online.
• VCP change — the only mid-run change type that ships an attachment (per attachmentForChange).

Other change types (power source flips, mode shifts without VCP) reach the user as text-only and don't justify a render. No-change polls now skip the image source entirely.

Why

The renderer is the heaviest hop in the pipeline (S3 fetch + Py-ART decode + Cartopy plot per request). Burning a full render every 5 min per station to discard the result was pure waste — and at scale it scales linearly with both station count and poll frequency.

Tests

Two new tests pin the regression:

• TestNoChangePollSkipsImageSource — repeated identical-data polls fetch exactly once (the startup poll), never on subsequent ticks.
• TestNonVCPChangePollSkipsImageSource — power-source flips don't trigger a fetch even though they fire a notification.

TestVCPChangeDeliversAttachment continues to pass: the freshly-rendered image still lands on the change notification because fetchRadarImage runs just-in-time in the VCP-change branch instead of opportunistically before comparison.

Test plan

• go test ./internal/monitor/... — passes (full suite)
• go test ./... — all packages green
• Verified the new tests assert request counts at each poll boundary

🤖 Generated with Claude Code

[wall-e-one]

🎉 This PR is included in version 2.13.1 🎉

The release is available on:

• v2.13.1
• GitHub release

Your semantic-release bot 📦🚀