internet-latency-collector: detect and replace unresponsive RIPE Atlas source probes

[snormore]

Summary of Changes

• Add per-source-probe staleness detection so the collector automatically replaces RIPE Atlas probes that stop sending pings, even when RIPE reports them as "Connected"
• Add 24-hour TTL to the unresponsive probe blacklist so probes get retried instead of being permanently banned — previously, locations with only one nearby probe (e.g. Pittsburgh) would permanently lose RIPE Atlas coverage
• Fix source probe comparison in measurement reconciliation to check probe IDs, not just location codes — a replaced probe at the same location was invisible to the reconciliation logic

Diff Breakdown

Category	Files	Lines (+/-)	Net
Core logic	2	+165 / -31	+134
Tests	2	+216 / -0	+216

~60% tests, ~40% core logic.

Key files (click to expand)

• controlplane/internet-latency-collector/internal/ripeatlas/collector_test.go — new test for unresponsive source probe detection end-to-end (stale probe → marked → measurement recreated with replacement)
• controlplane/internet-latency-collector/internal/ripeatlas/state_test.go — tests for source probe response tracking, probe expiry after 24h, and backwards-compatible loading of legacy []int state format
• controlplane/internet-latency-collector/internal/ripeatlas/state.go — LastResponseAt field on source probes, UnresponsiveProbeEntry struct with MarkedAt timestamp replacing bare []int, PruneExpiredUnresponsiveProbes(), backwards-compatible state loading
• controlplane/internet-latency-collector/internal/ripeatlas/collector.go — source probe staleness detection in configureMeasurements, response time tracking during export, regenerate wanted measurements after marking new probes unresponsive, probe ID comparison in reconciliation

Testing Verification

• New test TestInternetLatency_RIPEAtlas_ConfigureMeasurements_UnresponsiveSourceProbe validates the full flow: stale source probe detected → marked unresponsive → old measurement stopped → new measurement created with replacement probe from the same location
• New test TestInternetLatency_RIPEAtlas_State_UpdateSourceProbeResponse covers response timestamp tracking including monotonicity and edge cases
• New test TestInternetLatency_RIPEAtlas_State_UnresponsiveProbeExpiry verifies probes expire from blacklist after 24 hours
• New test TestInternetLatency_RIPEAtlas_State_UnresponsiveProbeBackwardsCompat verifies legacy [7466, 1234] state files are migrated to the new timestamped format on load

[nikw9944]

I think there might be a case we're still not handling. Each probe is involved in producing results in two ways: 1) By pinging other probes and reporting results in a ripe atlas measurement and 2) By responding to pings from other probes, which report results in different measurements. In #3173 the probe was broken in a way that prevented it from responding to pings from the "to sjc" measurement (way 2), even though it was still able to producing data when pinging other probes (way 1).

Would it make sense to update this PR to consider unresponsiveness of only one of the two ways? (Although that gets a little iffy when a probe is only using the way in question to ping or respond to pings from 1 probe.)