SSRF defense-in-depth: block IPv6 transition prefixes that can wrap
private IPv4 destinations on hosts with kernel sit0/NAT64 routes.

- `2002::/16` (6to4, RFC 3056 — deprecated by RFC 7526)
- `64:ff9b::/96` (NAT64 well-known, RFC 6052)
- `64:ff9b:1::/48` (NAT64 local-use, RFC 8215 — same SSRF threat class
  as the WKP; missing it earned a HackerOne bounty against
  ssrf_filter)
- `2001::/32` (Teredo, RFC 4380)
- `100::/64` (IPv6 discard, RFC 6666)
- `::/96` (IPv4-Compatible IPv6, RFC 4291 §2.5.5.1 — DEPRECATED 2006;
  same SSRF threat class as the transition prefixes)

The metadata-IP block is hardened against IPv6-wrapped IMDS access:
when an IPv6 destination falls in a NAT64 prefix, the embedded IPv4 is
extracted and matched against `ALWAYS_BLOCKED_METADATA_IPS`, so
`[64:ff9b::a9fe:a9fe]` cannot reach 169.254.169.254 even on a NAT64
host.

Operators on IPv6-only deployments using DNS64+NAT64 (where outbound
IPv4 traffic is synthesized through `64:ff9b::/96`) can opt back in via
the env-only setting `security.allow_nat64`
(`LDR_SECURITY_ALLOW_NAT64=true`). The opt-in is scoped strictly to
the two NAT64 prefixes — 6to4, Teredo, and discard remain blocked
unconditionally, and the IMDS embedded-IPv4 carve-out still applies.
