[docker-in-docker] v4 with iptablesSwitchAtRuntime:true default on Ubuntu 26.04 host/devcontainer image activates iptables-legacy instead of iptables-nft

After upgrading the devcontainer configuration of [siemens/ghostwire](https://github.com/siemens/ghostwire) to use an Ubuntu 26.04 base image and the `docker-in-docker:4` feature on a Ubuntu 26.04 host a test related to nft packet forwarding rules failed. Diving deeper revealed that the `docker-in-docker:4` feature with the default setting `iptablesSwitchAtRuntime:true` activates `iptables-legacy` instead of `iptables-nft`.

It seems that the feature sees that `ip_tables` is listed in `/proc/modules` and thus unfortunately falls on the wrong side of the slice of bread, activating `iptables-legacy`.

Forcing `iptablesSwitchAtRuntime:false` correctly activates `iptables-nft` instead when building on this host.

The problem now is that when other users/projects use the default `iptablesSwitchAtRuntime:true` setting they end up with the legacy when the nft would have been the better choice: as there is no Go native iptables (legacy) interface module available, but there is a Go native nftables module from Google, not least Edgeshark/Ghostwire as well as some other tools cannot correctly figure out the port forwarding inside dev containers when using these diagnosis tools.

Would it be possible to fix this in the way that `iptables-nft` gets activated when `nf_tables` is available, as well as `iptables-nft`? This would hopefully make the slice of bread fall on the better side for many unsuspecting devcontainer feature users.