Ping.canaries has no maximum-entry contract, enabling unbounded map allocation at the Node

[bibonix]

The canaries field in ping.proto (map<string, uint32> canaries = 2) has no documented upper bound on the number of entries. The comment describes it as per-peer probe-failure counters accumulated since the previous Ping, implying the map size is bounded by the fleet size in practice — but the proto imposes no such constraint.

A client can send a single Ping carrying thousands of fabricated map entries. The Node must deserialize the entire map before discarding or forwarding it to the Hub, allocating memory proportional to the entry count. Because a Ping arrives every few seconds per session, the exposure is multiplied by the number of active sessions.

The analogous Auth.padding and Welcome.padding fields each have open issues noting the missing maximum-size contract (see #18 and #19); the canaries map is subject to the same class of issue without even the justification of being a padding field.

A comment naming the practical upper bound — the fleet size, currently on the order of dozens of Nodes — would close the contract. The Node should discard or truncate a Ping whose canaries map exceeds that bound.

See ping.proto line 17 (canaries = 2).

[bibonix]

@davvd happy to clarify the proposed bound or discuss whether the Node should truncate silently or close the connection when the limit is exceeded.