fix: support IPv6 traceroute in Connection Monitor

[itsDNNS]

Problem

Discussion #359 confirmed that IPv6 targets now work for the normal Connection Monitor probe after #362, but the traceroute path still appears to be IPv4-only.

Current code check:

• tools/traceroute_helper.c opens only AF_INET raw ICMP sockets.
• target resolution uses hints.ai_family = AF_INET via resolve_ipv4().
• hop formatting uses INET_ADDRSTRLEN and inet_ntop(AF_INET, ...).
• there is no ICMPv6 / AF_INET6 traceroute handling.

Result: an IPv6 target can be reachable by the monitor itself, while manual or triggered traceroute still cannot trace it.

Proposed direction

Add dual-stack traceroute support rather than documenting this as a setup issue.

Implementation split:

1. Resolve traceroute targets with getaddrinfo(AF_UNSPEC) and choose a usable IPv4 or IPv6 address.
2. Preserve the existing IPv4 ICMP traceroute behavior.
3. Add ICMPv6 traceroute support using AF_INET6, IPPROTO_ICMPV6, hop limit control, and ICMPv6 Time Exceeded / Echo Reply parsing.
4. Keep the helper output format compatible with the Python parser: hop_index, hop_ip, latency_ms, probes_responded.
5. Update tests for Python wrapper behavior and add compile-level or helper-focused regression coverage where practical.
6. Mention the traceroute IPv6 behavior in the Connection Monitor documentation if the docs currently imply full IPv6 support.

Acceptance criteria

• Manual traceroute for an IPv6 literal such as 2606:4700:4700::1111 no longer fails solely because DOCSight only resolves IPv4.
• IPv6-only hostnames can be traced when the host/container has IPv6 routing.
• Existing IPv4 traceroute behavior and output remain unchanged.
• Docker NET_RAW / setuid helper behavior stays compatible with the current image.
• Tests cover the IPv4-only regression path that was left behind after fix: support IPv6 connection monitor targets #362.

Related: #359 (reply in thread)