[28.x backport] Unmap IPv4 addresses loaded from store

[robmry]

• backport Unmap IPv4 addresses loaded from store #50827

- What I did

• related to Regression in v28.2: xtables contention detected while running [--wait -t raw -C PREROUTING -d ::ffff:172.29.29.107 ! -i br-9f6f70b73462 -j DROP]: Waited for 56.12 seconds and received "" #50692

IPv4-mapped IPv6 addresses are accepted by iptables, and do the right thing (so there's no obvious behavioural change). But, maybe this will help with the linked issue, or at-least rule out a potential difference from rules in 28.0.x.

- How I did it

When converting an endpoint's IPv4 net.IPNet to a netip.Addr, unmap it so that iptables rules don't contain IPv4-mapped IPv6 addresses - which they do otherwise, when the net.IPNet is loaded from the store.

- How to verify it

• Enable live-restore.
• docker network create b4
• docker run -d --rm --network b4 --name c1 busybox top
• Restart the daemon.

Without the change ...

DEBU[2025-08-27T16:21:36.545721342Z] Network (33c8cf6) restored
DEBU[2025-08-27T16:21:36.545868426Z] /usr/sbin/iptables, [--wait -t raw -C PREROUTING -d ::ffff:172.19.0.2 ! -i br-c4ed16cae1fd -j DROP]
DEBU[2025-08-27T16:21:36.546533634Z] Endpoint (8f9cd0f) restored to network (c4ed16c)

With the change ...

DEBU[2025-08-27T16:20:24.777808878Z] Network (170c742) restored
DEBU[2025-08-27T16:20:24.777946628Z] /usr/sbin/iptables, [--wait -t raw -C PREROUTING -d 172.19.0.2 ! -i br-c4ed16cae1fd -j DROP]
DEBU[2025-08-27T16:20:24.778534628Z] Endpoint (8f9cd0f) restored to network (c4ed16c)

- Human readable description for the release notes

- Fix an issue that could cause slow container restart on live-restore.

[thaJeztah]

LGTM