findings: v6.broken claimed a cause it had no evidence for

A phone reported "IPv6 is configured but not working" while loading an IPv6-only
site over TCP perfectly well. The finding fired on one signal - ICMPv6 echo
getting no reply - at HIGH confidence. ICMPv6 echo is widely filtered on
networks where IPv6 works, so the two cases are indistinguishable from where the
app stands, and it was picking one.

Same class of error as the multi-homed downstream-loss bug: a confident
measurement of something that was not happening. Now v6.no_icmp_reply, low
severity, medium confidence, naming both explanations. Still reported, because
filtered ICMPv6 breaks Path MTU Discovery - large packets vanish instead of
being reported as too big - which is a fault in its own right.

Corroborating with a real IPv6 connection would separate the two properly, but
needs a target, which runs into the hardcoded-deployment issue already open.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

echolot-app/core-measurement/src/main/kotlin/app/echo_lot/measurement/FindingRegistry.kt

@@ -169,10 +169,22 @@ object FindingRegistry {
     // they silently rolled up under connectivity: the third instance of a prefix disagreeing with
     // its category and quietly moving a fault to a different verdict light.
 
-    val V6_BROKEN = FindingSpec(
-        "v6.broken", Category.IPV6, Severity.MEDIUM,
-        "IPv6 is configured on this network but does not work.",
-        rulesOut = "Absence of IPv6: it is provisioned, it simply fails.",
+    /**
+     * Renamed from `v6.broken`, which claimed more than the evidence supports.
+     *
+     * The only signal behind it is ICMPv6 echo getting no reply — and ICMPv6 echo is widely
+     * filtered on networks where IPv6 otherwise works perfectly. A phone that reported this while
+     * happily loading an IPv6-only site over TCP is what caught it. From here the two cases look
+     * identical, so the finding now says what was observed and names both explanations rather than
+     * picking one.
+     *
+     * It is worth reporting either way: filtered ICMPv6 breaks Path MTU Discovery, which is its
+     * own fault even when IPv6 works.
+     */
+    val V6_NO_ICMP_REPLY = FindingSpec(
+        "v6.no_icmp_reply", Category.IPV6, Severity.LOW,
+        "IPv6 is configured but ICMPv6 echo gets no reply.",
+        rulesOut = "Nothing on its own: IPv6 may work fine with ICMP filtered.",
     )
 
     /**
@@ -196,7 +208,7 @@ object FindingRegistry {
         NAT_UDP_REBINDING, NAT_SYMMETRIC,
         THROUGHPUT_NO_DELIVERY, THROUGHPUT_BELOW_OFFERED,
         DNS_ANSWER_REWRITTEN, DNS_AUTHORITATIVE_UNREACHABLE,
-        V6_BROKEN, V6_NOT_OFFERED,
+        V6_NO_ICMP_REPLY, V6_NOT_OFFERED,
     )
 
     private val byCode: Map<String, FindingSpec> = all.associateBy { it.code }