Write the path hash size on zero hop packets 🤖🤖

[TeTeHacko]

sendZeroHop() sets packet->path_len = 0 to mean "no path segments". That byte also carries the path hash size in its upper 2 bits (Packet.h), so the assignment clears the size too, and every zero hop packet goes out declaring a 1-byte path hash regardless of the node's path.hash.mode. sendFlood() already takes a path_hash_size and writes it through setPathHashSizeAndCount(); this makes sendZeroHop() do the same.

Why it matters

Routing is unaffected — a zero hop packet carries no path and is never repeated (Mesh.cpp gates on getPathHashCount() > 0). What it affects is what a node reports about itself, because observers derive a node's hash size from the packets they hear. A node configured for 2 bytes sends its flood adverts as 2-byte and its periodic local adverts as 1-byte, so it appears inconsistent and downstream tooling has had to special-case zero hop adverts.

This was reported in #2154. The mechanism was identified correctly there ("sendFlood is now correctly using the path hash mode ... however sendZeroHop ... doesn't") but the behaviour was left as is, and it was independently reproduced in that thread across firmware 14.0–15.0 on several boards. The question asked there and not answered was whether changing it would break older firmware — see the next section.

Measured on the Czech community mesh, counting only packets that carry at least one hop (where the width is corroborated by the path length rather than just declared): 849 packets from 158 senders at 2 bytes, 107 from 4 senders at 3 bytes, 85 from 32 senders at 1 byte. Zero hop packets have to be excluded from that kind of census entirely, which is exactly the workaround this change removes the need for.

Backwards compatibility

Receivers already tolerate a non-zero size on a zero hop packet. Dispatcher.cpp reads

uint8_t path_mode = pkt->path_len >> 6;  // upper 2 bits (legacy firmware: 00)
...
uint8_t path_byte_len = (pkt->path_len & 63) * pkt->getPathHashSize();

so the size is masked out of the hop count and the legacy 00 is already accounted for. Nothing in the tree compares the whole path_len byte against zero to detect a zero hop packet. A zero hop packet that now declares 2 or 3 bytes parses correctly on existing firmware.

Scope

path_hash_size defaults to 1, so any caller that does not pass a size produces byte-identical output to today. Examples that have a path.hash.mode setting now pass it, mirroring their adjacent sendFlood() calls. Two call sites deliberately keep the default:

• BaseChatMesh::shareContactZeroHop() rebroadcasts another node's stored advert blob, so this node's setting does not apply.
• simple_secure_chat has no path.hash.mode in its NodePrefs at all.

Note that the second sendZeroHop() overload takes uint16_t* transport_codes, so a bare 0 for delay_millis becomes ambiguous once a fourth parameter exists; the affected call sites pass (uint32_t)0.

Testing

• pio test -e native -e native_kiss_modem — 48/48 pass.
• Built Heltec_v3_repeater, Heltec_v3_companion_radio_ble, Heltec_v3_room_server, RAK_4631_repeater, PicoW_repeater, wio-e5-mini_repeater, plus Heltec_t096_sensor and PicoW_terminal_chat — the last two cover simple_sensor and simple_secure_chat, which the PR build matrix does not include but this change touches.

Related to #2154.