Thread BR fixes

Most important thing first: even with your original code, I cannot reproduce your case where you lose Wifi the moment Thread connects. I can only guess what this is, but it might be either your esp32c6 chip (if it is older / pre-release), or something specific to your network.

With that said:

• I've changed esp-idf-svc Thread BR code a bit, as setting the backbone netif (= Wifi) was being done too late, and also - to set it as early as necessary - it cannot be done safely
• I've simplified a bit your code; removed the sdkconfig.debug thing, provided a proper sdkconfig.defaults thing, and simplified also quite a bit your Cargo.toml
• The Rust code now follows the correct initialization sequence:
  • The Wifi driver must be constructed first, and before setting its netif as a backbone one, it must be started (but it is not necessary to wait for the Wifi to connect before doing that; above all, you might need to reconnect anyway if the wifi connection is lost)
  • Software COEX is now enabled. Not sure it is 100% necessary, but the claims are it results in a more stable Wifi + Thread connections
  • You MUST assign a link-local ipv6 address to the Wifi netif; this is now done
  • Ideally, you should instantiate/start the mDNS responder too; this is now done

With all the above changes, the BR does work for me, however its two non-link-local ipv6 addresses are not pingable. Whether these should be pingable in the first place, I'm not really sure - one of these shouldn't as it is only for within the Thread network, but the other?

I'm also not sure what you are trying to achieve, but if you just want to (re)implement the Thread BR "in Rust", you might also need another esp32c6 board which should serve as a Thread FTD/MTD device, and which should be configured with the same Thread credentials as the Border Router. If it joins the Thread network successfully, then that one for sure should be pingable "from outside" Thread (i.e. from your laptop) or else the BR still does not work correctly.