internet-latency-collector: exclude probes tagged system-ipv4-doesnt-work

[nikw9944]

Summary

• The RIPE Atlas collector drops any probe RIPE tags system-ipv4-doesnt-work at fetch time, so it can never be chosen as a measurement target, a measurement source, or a fallback candidate.
• Probe gains a Tags field; /probes/ already returns tags in the default representation, so no API change was needed.
• Filtering lives only in filterValidProbes, the single chokepoint every probe fetch path runs through. One Info log line names each excluded probe and the tag.
• The tag is hardcoded on purpose. It is a fact about RIPE's data model, not a tuning knob, so there is no flag or config list.

Why

Columbus (cmh) has no RIPE anchor, so the collector falls back to the nearest Connected probe carrying an IPv4 address. That is probe 1009793 at 0.36 km. RIPE auto-assigns it system-ipv4-doesnt-work — the probe cannot perform IPv4 measurements — and it never answers a ping.

The result was a loop with no exit. The collector selected it, waited an hour, marked it never_exported, blacklisted it for 24h, then the mark expired and it was re-selected because it was still nearest. Production logs on the mainnet-beta collector host show the full cycle: marked 2026-09-13T19:00:29Z, pruned 2026-09-14T19:00:29Z, re-adopted 2026-09-14T20:00:30Z (Measurement has outdated target probe, marking for recreation ... existing_probe_id 12651, wanted_probe_id 1009793). Excluding the tag at fetch time removes the probe from candidacy permanently and adds no new state.

The collector only ever measures IPv4 (Probe.Address is address_v4), so a probe whose IPv4 does not work is unusable in every role.

The mirror tag system-ipv4-works is deliberately not required. Probe 1012487 near cmh answers pings and carries neither tag, so only the explicit negative is a safe exclusion.

Notes for reviewers

• list-probes output also omits tagged probes, since it reaches probes through the same filter. For a diagnostic view, annotating rather than omitting them would be more useful — worth a follow-up.
• internet-latency-collector: rotate lossy ripe atlas target probes #4331 adds the same Tags field with the same shape and placement, so it needs a trivial rebase once this merges.

Testing Verification

• filterValidProbes table test: a probe tagged system-ipv4-doesnt-work is dropped despite a routable address; the same holds when it also carries system-ipv4-works; probes tagged system-ipv4-works, tagged only with unrelated slugs, or carrying no tags at all are kept; the existing empty-address, private-address and loopback rejections and the routable-IPv6 acceptance still hold.
• JSON decode test: a /probes/ response body with a tags array populates Probe.Tags with both name and slug, and hasTag matches on slug.
• go test ./controlplane/internet-latency-collector/... and golangci-lint run on the same tree pass.