gossipd: fix excessive msg_queue length from status_trace()

When this (very spammy) "handle_recv_gossip" message was changed
from debug to trace, the suppression code wasn't updated: we suppress
overly active debug messages, but not trace messages.

This is the backtrace from an earlier version of the "too large queue"
patch:

```
lightning_gossipd: msg_queue length excessive (version v24.08.1-17-ga780ad4-modded)
0x557e521e833f send_backtrace
        common/daemon.c:33
0x557e521eefb9 do_enqueue
        common/msg_queue.c:66
0x557e521ef043 msg_enqueue
        common/msg_queue.c:82
0x557e521e891d daemon_conn_send
        common/daemon_conn.c:161
0x557e521f14f0 status_send
        common/status.c:90
0x557e521f1804 status_vfmt
        common/status.c:169
0x557e521f1433 status_fmt
        common/status.c:180
0x557e521de7c6 handle_recv_gossip
        gossipd/gossipd.c:206
0x557e521de9f5 connectd_req
        gossipd/gossipd.c:307
0x557e521e862d handle_read
        common/daemon_conn.c:35
```

common/status.c

@@ -151,15 +151,15 @@ void status_vfmt(enum log_level level,
 
 	/* We only suppress async debug msgs.  IO messages are even spammier
 	 * but they only occur when explicitly asked for */
-	if (level == LOG_DBG && status_conn) {
+	if ((level == LOG_DBG || level == LOG_TRACE) && status_conn) {
 		size_t qlen = daemon_conn_queue_length(status_conn);
 
 		/* Once suppressing, we keep suppressing until we're empty */
 		if (traces_suppressed && qlen == 0) {
 			size_t n = traces_suppressed;
 			traces_suppressed = 0;
 			/* Careful: recursion! */
-			status_debug("...[%zu debug messages suppressed]...", n);
+			status_debug("...[%zu debug/trace messages suppressed]...", n);
 		} else if (traces_suppressed || qlen > TRACE_QUEUE_LIMIT) {
 			traces_suppressed++;
 			return;