fix(uavcan): classify TX frames dropped while peeking the queue (#28397)

peek() discards entries whose deadline has passed before returning the head of
the queue, and counted them with a bare registerRejectedFrame(). That is the
fourth drop path; the reported split covers three. The frames landed in the
total and in neither bucket, so `uavcan status` printed lines like

	TX rejected:   64 frames (0 expired, 0 no memory)

which reads as "no drops worth caring about" when 64 frames of in-flight
transfers had just been discarded. Serving a DroneCAN node firmware update hits
this path on every interface.

The total stays a separate counter rather than the sum of the two buckets: it is
what makes an unclassified path visible at all, which is how this one was found.

src/drivers/uavcan/libdronecan/libuavcan/include/uavcan/transport/can_io.hpp

@@ -117,6 +117,8 @@ public:
     /// The 'or equal' condition is necessary to avoid frame reordering.
     bool topPriorityHigherOrEqual(const CanFrame& rhs_frame) const;
 
+    /// Total. Every drop is also counted in exactly one of the two below, so a total that exceeds
+    /// their sum means a drop path was added without classifying it.
     uint32_t getRejectedFrameCount() const { return rejected_frames_cnt_; }
 
     /// Frames dropped because their transmit deadline had already passed. Not a memory shortage.

src/drivers/uavcan/libdronecan/libuavcan/src/transport/uc_can_io.cpp

@@ -207,7 +207,7 @@ CanTxQueue::Entry* CanTxQueue::peek()
         {
             UAVCAN_TRACE("CanTxQueue", "Peek: Expired %s", p->toString().c_str());
             Entry* const next = p->getNextListNode();
-            registerRejectedFrame();
+            registerExpiredFrame();
             remove(p);
             p = next;
         }