Describe the bug
I have created a private encrypted channel with my friend (manually added - channel index # 2) where we use to chat when routing works bad (flood routing for channels helps a lot).

Since then, all traceroutes I request from my friend are sent over this encrypted channel (# 2) instead of Primary channel #0 (LongFast).

This causes encrypted payload and other nodes cannot modify the encrypted traceroute packet resulting a lot of "Unknown" in the route, basically making traceroutes sent from MeshMonitor useless:
■ MY_NODE
⇊ 🟥 -32 dB
■ Unknown
⇊ 🟥 -32 dB
■ Unknown
⇊ 🟩 -6 dB
■ FRIEND_NODE

Route traced back to us:

■ FRIEND_NODE
⇊ 🟥 -32 dB
■ Unknown
⇊ 🟥 -32 dB
■ Unknown
⇊ 🟨 -7.25 dB
■ MY_NODE_2 (over UDP)
■ MY_NODE

How it looks in MeshMonitor:

Traceroutes should always be sent over Primary unencrypted channel so other nodes can modify the packet to avoid "Unknown" in the whole traceroute.

It is confirmed by a few dozens of traceroutes so it is not just a corrupted data during the traceroute.

Also, how the channel looks:

How it should look:

A temporary workaround is:

1. Click the dropdown menu button near "📍 Exchange Position▾"
2. Select "Channel 0 (Primary)"

This way, after position request is sent and the response is received, it starts to send traceroute requests over Primary channel but only temporary, seemingly until any message in the private channel is received.

To Reproduce
Steps to reproduce the behavior:

1. Create a custom secondary channel
2. Exchange a few messages with another node in this channel
3. Try to traceroute this none making the traceroute pass through other nodes (these nodes should not have this channel in their channel list)

Expected behavior
Normally, it should not affect the default channel for Traceroute and traceroute should be sent over Primary unencrypted channel (#0).

Actual behavior
Traceroutes are sent over the secondary encrypted channel and other nodes cannot modify the traceroute packet resulting a lof of "Unknown" nodes in the route.

Environment (please complete the following information):

• Host OS: Windows
• Deployment type: Windows App
• Version: v4.11.3
• Any networking customizations (Reverse proxies, Cloudflare tunnels, Tailscale, etc): None
• Database backend: Not sure, the default Windows App from releases
• Node type: Heltec V4
• Node Connection Type: Wifi
• • If this is about VirtualNode, then what client are you using for testing? It is not about a VirtualNode