Preserve direct path length when decoding contact frames

pathLen is read as an unsigned byte, but this assignment maps every pathLen <= 0 to -1, so a valid direct route (pathLen == 0) is now decoded as flood. That changes routing behavior (pathLength < 0 is treated as flood throughout the connector) and can break follow-up writes that pass this value back into buildUpdateContactPathFrame (which writes pathLen as a byte). Keep 0 as direct and only map the flood sentinel to -1.

Useful? React with 👍 / 👎.

Read contact last-seen from the correct offset

This refactor now stores lastSeen from the first 4-byte field after the name, but the protocol defines that field as contactTimestampOffset (132) and the real last-modified value at contactLastModOffset (144) in lib/connector/meshcore_protocol.dart. Because the parser no longer skips the timestamp field before assigning lastSeen, contact freshness/order can regress to stale or incorrect times.

Useful? React with 👍 / 👎.

readCString() sets _lastPointer at the start, but then calls readByte() in a loop; readByte() delegates to readBytes(), which overwrites _lastPointer on every iteration. As a result, rewind() after readCString() will only rewind a single byte (and the initial _lastPointer = _pointer in readCString() is effectively lost). If rewind() is meant to undo the whole readCString() call, preserve the starting offset (e.g. store it locally and restore _lastPointer at the end, or implement the scan using a single readBytes() call).

pathLen is read as an unsigned byte, but contact frames previously treated it as a signed int8 (e.g. 0xFF => -1). With the current readByte() approach, a flood sentinel (0xFF) becomes 255, which makes safePathLen clamp to maxPathSize and populates pathBytes even when there should be no path. Read this as a signed value (e.g. readInt8() / .toSigned(8)) and keep safePathLen based on the signed value.

pathLength is being normalized to -1 when pathLen <= 0, which turns the direct case (pathLen == 0) into flood. This will break Contact.pathLabel and outgoing path selection (the code treats pathLength == 0 as direct and < 0 as flood). Preserve 0 for direct and only map negative values (and/or invalid > max) to flood.

pathLength is set to -1 when pathBytes is empty, which reclassifies direct adverts (empty path, non-flood route) as flood. This also creates an inconsistency with _handlePayloadAdvertReceived, which later refreshes existing contacts using pathLength: path.length (0 for empty). Consider deriving flood vs direct from routeType (or keep pathLength: pathBytes.length and only force -1 when the route type is a flood variant).

pathLen is read as an unsigned byte (readByte()), but contact pathLength semantics in this codebase rely on a signed int8 (<0=flood, 0=direct, >0=hops). This makes flood routes impossible to represent and will also mis-handle values >= 128. Read this field as signed (e.g., readInt8() / .toSigned(8)) and keep safePathLen logic based on the signed value.

The pathLength mapping here converts pathLen == 0 (direct) into -1 (flood), which contradicts the pathLabel logic and model docs (-1=flood, 0=direct). Preserve 0 for direct, and only use <0 for flood (or derive flood/direct from the signed pathLen field).

readCString() sets _lastPointer at the start, but then calls readByte() in a loop; readByte() updates _lastPointer on every iteration via readBytes(1). As a result, rewind() will jump back only one byte (or some mid-string position) instead of rewinding the whole CString read. Consider implementing readCString() without calling readByte()/readBytes() (read from _buffer[_pointer] directly) or ensure _lastPointer remains the starting pointer for the entire CString operation.

resetPointer() resets _pointer but leaves _lastPointer unchanged, so a subsequent rewind() after a reset can jump to an unrelated earlier offset. Resetting should likely also reset _lastPointer to 0 (or to the new _pointer) to keep rewind behavior consistent.

Setting pathLength to -1 whenever pathBytes is empty loses the distinction between direct (0 hops) and flood (-1). Since routeType is already parsed above, consider setting pathLength based on routeType when pathBytes.isEmpty (e.g., direct -> 0, flood -> -1) to keep DiscoveryContact.pathLabel accurate.