Summary

Add TRACEROUTE_APP to the list of portnums exempt from TrafficManagementModule's rate limiter, alongside the existing ROUTING_APP and ADMIN_APP exemptions.

Problem

In TrafficManagementModule::handleReceived():

if (cfg.rate_limit_enabled && cfg.rate_limit_window_secs > 0 && cfg.rate_limit_max_packets > 0) {
    if (mp.decoded.portnum != meshtastic_PortNum_ROUTING_APP && mp.decoded.portnum != meshtastic_PortNum_ADMIN_APP) {
        if (isRateLimited(mp.from, nowMs)) {
            logAction("drop", &mp, "rate-limit");
            incrementStat(&stats.rate_limit_drops);
            ignoreRequest = true;        // Suppress NAK
            return ProcessMessage::STOP;
        }
    }
}

Traceroute packets (TRACEROUTE_APP) flow on the same node→node DM channels as user traffic and are therefore subject to the same per-source rate limit. When a router node has rate_limit_enabled = true (the intended behavior for congested deployments), traceroute responses get silently dropped whenever the originating node happens to be slightly chatty, and the initiator sees incomplete or missing paths.

The failure mode is particularly bad because:

• It is silent — the ignoreRequest = true; return STOP; path suppresses the NAK, so the initiator cannot distinguish "no route" from "route was discovered but the reply was rate-limited on an intermediate hop."
• Traceroute is inherently low-volume (one request + one response per invocation) and operator-initiated. Rate-limiting it does not protect the mesh from any real abuse vector, but it does make diagnosing other mesh problems much harder.
• Fleet operators typically run traceroute because something is wrong, which is exactly when rate limits are most likely already tripping on chatty nodes.

Fix

Add TRACEROUTE_APP to the exempt list and refactor the check into a named boolean for readability:

if (cfg.rate_limit_enabled && cfg.rate_limit_window_secs > 0 && cfg.rate_limit_max_packets > 0) {
    const auto pn = mp.decoded.portnum;
    const bool rateLimitExempt = (pn == meshtastic_PortNum_ROUTING_APP ||
                                  pn == meshtastic_PortNum_ADMIN_APP ||
                                  pn == meshtastic_PortNum_TRACEROUTE_APP);
    if (!rateLimitExempt) {
        if (isRateLimited(mp.from, nowMs)) {
            ...
        }
    }
}

Also update the adjacent comment.

Testing

• Patched firmware running on router nodes with rate_limit_enabled = true, rate_limit_window_secs = 60, rate_limit_max_packets = 8. Traceroute from neighboring nodes now reliably returns a complete path even when the source node is simultaneously sending position/telemetry.
• Builds cleanly against develop.

Risk

Minimal. Moves one portnum from "subject to rate limit" to "exempt from rate limit." No path change for any other traffic class. Traceroute is already rate-limited elsewhere in the stack by its intrinsic once-per-operator-command cadence.