Ignore prepended all-zero hops when calculating max flood hops

[vaizki]

Summary

Adds Packet::getPathHashCountExcludingLeadingZeros() and uses it for flood forwarding policy checks. Leading all-zero path entries are treated as synthetic padding for all flood max decisions, while the existing raw Packet::getPathHashCount() behavior is left unchanged for path encoding, append position, priority, and the 64-byte path capacity check.

Motivation

For sensor telemetry, I want to send flood-routed packets but limit how far they propagate. MeshCore does not have a TTL field, but flood routing already stops when another repeater hash no longer fits in Packet::path (64 bytes). So I am abusing this length limit by prefilling the route with reserved values (zeros). This already works without this PR.

With the new flood max config options (all, unscoped, adverts) it's expected that flood propagation will be limited by repeater admins by using these knobs to cut down on flood from lands far away. However this will completely kill the prepending zeros trick. Thus this PR to ignore prepended all-zero IDs in paths when counting for the max hop limiters.

Other use cases

It's a generic TTL mechanism. Use it to limit all kinds of flood packets . This PR targets only the routing part, not actual applications in companions / sensors etc.

Other solutions considered

• Custom scope - cleanest but not always possible because you don't control all the routers along the path(s).
• Not doing anything and watching my solar node battery stats cross the continent..

Example

Example with 3-byte path hashes:

• prefill 17 leading 000000 path entries;
• this consumes 51 of MAX_PATH_SIZE == 64 bytes;
• only 4 real 3-byte repeater hashes can still be appended;
• the 5th repeater cannot forward because (21 + 1) * 3 > 64.

Behavior

Patched firmware:

• uses Packet::getPathHashCountExcludingLeadingZeros() in allowPacketForward() checks for flood_max, flood_max_unscoped, and flood_max_advert;
• still uses Packet::getPathHashCount() in Mesh::routeRecvPacket() for raw append/capacity behavior;
• therefore repeaters with e.g. flood.max = 12 can still forward a packet with 17 synthetic leading-zero entries, while path capacity limits it to 4 real repeats.

Existing 1.14.0+ firmware:

parses the multibyte path normally;
counts the synthetic entries as normal hops for flood.max;
still honors the raw path capacity limit;
may drop early if its configured flood.max is lower than the prefilled count.

Adverse side-effects

• Packets will have a much longer path = more airtime. But weighed against unnecessary flooding it is acceptable.

Scope of changes

This does not change the wire format, Packet::readFrom(), Dispatcher::tryParsePacket(), or direct routing. It only changes flood policy accounting in the repeater/room-server/sensor forwarding checks.