feat(telemetry): count relayed transactions this node did not process

Moving the tx.receive span past the duplicate check removed the only record of
why a relayed copy was dropped. A labelled counter restores it, and covers the
inner-batch reject the span never usefully reached.

The count itself was never span-derived: transactions_duplicate already totals
the dropped copies and predates the telemetry work. What was missing is the
split between ordinary relay overlap and a peer sending traffic it should not.

A counter also survives sampling and runs with tracing off, which the span
attribute did not.

include/xrpl/telemetry/MetricNames.h

@@ -253,6 +253,10 @@ inline constexpr char peerAcceptTotal[] = "peer_accept_total";
  * Peer disconnects, by cause and connection direction.
  */
 inline constexpr char peerDisconnectTotal[] = "peer_disconnect_total";
+/**
+ * Relayed transactions this node did not process, by reason.
+ */
+inline constexpr char peerTxRejectedTotal[] = "peer_tx_rejected_total";
 /**
  * Peer data requests this node declined to serve, by kind and cause.
  */
@@ -762,6 +766,22 @@ inline constexpr char graceful[] = "graceful";
 inline constexpr char readError[] = "read_error";
 }  // namespace disconnect
 
+/**
+ * `peer_tx_rejected_total` reasons -- why a relayed transaction was not
+ * processed.
+ *
+ * `duplicate` is ordinary relay overlap and dominates, because a peer relays
+ * every transaction it hears. `known_bad` and `inner_batch` mean a peer sent
+ * traffic it should not, so the split is what separates normal overlap from a
+ * misbehaving peer. The total across reasons matches the
+ * `transactions_duplicate` traffic category for the first two.
+ */
+namespace tx_rejected {
+inline constexpr char duplicate[] = "duplicate";
+inline constexpr char knownBad[] = "known_bad";
+inline constexpr char innerBatch[] = "inner_batch";
+}  // namespace tx_rejected
+
 /**
  * `serve_refused_total` request kinds: what the peer had asked for.
  */