On a network that only permits one combined IPv4+IPv6 PDN context per APN, interfaces wwan <name> with both address dhcp and (address dhcpv6 or ipv6 address autoconf) fails to get an IPv6 address at all, even though the modem/network genuinely support dual-stack.

Root cause: mmcli --simple-connect ip-type=ipv4v6 (used in interfaces_wwan.py) opens two separate QMI WDS sessions internally — one IPv4-only, one IPv6-only — rather than negotiating both families together. The standalone IPv6 Start Network request is rejected outright by the network (CallEndReason: ip-version-mismatch), confirmed via ModemManager debug logging (mmcli --manager-set-logging=DEBUG) against a real Sierra MC7455 on a real carrier network (Google Fi/T-Mobile). Phones and other UEs never hit this because they negotiate both families together as part of the LTE attach's default EPS bearer, not via a later explicit per-family WDS call.

Fix: pre-negotiate the attach-time PDN type via mmcli --3gpp-set-initial-eps-bearer-settings before --simple-connect, whenever ip-type includes IPv6. Confirmed live: bearer.ipv6-config.* goes from unset to a real address/gateway/DNS, with a working ping -6. Non-fatal if the modem/network doesn't support the pre-step — it just proceeds to --simple-connect exactly as before.

Not a breaking change: gated entirely behind ip-type including IPv6, so existing IPv4-only WWAN configs never execute the new code path. Caveat: verified against hardware/network combinations where the ip-version-mismatch bug does manifest; not verified against a dual-stack setup where the existing split-WDS-session approach already works, though the pre-step is designed to be a no-op there (it requests the same ip-type --simple-connect is about to request anyway, and fails silently if unsupported).