bug: zero-hop detection reads the path byte at the wrong offset for transport-direct adverts #2225

Split off from #2190, where it was deferred to its own PR.

Problem

nodeZeroHopRegionCounts (cmd/server/store.go, at the head of #2190) decides that a direct ADVERT is zero-hop by reading the path byte at RawHex[2:4]. It does this for both ROUTE_TYPE_DIRECT and ROUTE_TYPE_TRANSPORT_DIRECT.

For the transport route types the packet carries 4 bytes of transport codes between the header and the path length. The format is [header][transport_codes(optional)][path_length][path][payload], with transport codes present only for ROUTE_TYPE_TRANSPORT_FLOOD and ROUTE_TYPE_TRANSPORT_DIRECT (firmware docs/packet_format.md). So for ROUTE_TYPE_TRANSPORT_DIRECT, RawHex[2:4] is the first byte of transport_code_1, not path_length.

The comment above that read says it matches the analytics decoder. It does not: the analytics code in the same file uses pbOffset = 5 for both transport route types.

Effect

A transport-direct zero-hop advert counts as zero-hop only when the low 6 bits of its first transport-code byte happen to be 0.

• It feeds the Bug/feature: Use actual repeaters region data and not observer based #804 home-region tally.
• Since fix(nodes): place nodes in regions by zero-hop home regions (#1879) #2190, it also feeds the zero_hop region placement. In that case the fewest-hops fallback still places the node, because path_json [] counts as 0 hops, but its basis is fewest_hops instead of zero_hop.

Fix

• Use the same offset rule as the analytics decoder: path byte at offset 5 for route types 0 and 3, offset 1 otherwise. Ideally this becomes one shared helper used by both.
• Add a test with a transport-direct zero-hop advert whose first transport-code byte is non-zero.