Fix: Scanner classifies device as v.3.4 when unable to confirm

[jasonacox]

The scanner output is misleading when it can't determine the actual protocol version.

What was happening:

When the scanner sends unencrypted queries and the device accepts the connection but then immediately closes it (3 times), this is characteristic behavior of v3.4/3.5 devices that require encrypted session key negotiation. However, the scanner was incorrectly reporting these devices as "v3.4" even when it never got a response to confirm the actual version.

The fixes:

Corrected v3.5 detection priority - When testing both v3.4 and v3.5 protocols, the code now checks for the v3.5 prefix (0x00006699) first, then v3.4 (0x000055aa). This fixes cases where v3.5 devices were being misidentified as v3.4.

Accurate version reporting - Devices that never respond will now show version 0.0 (displayed as ??) instead of falsely claiming to be v3.4.

Clearer error messages - When version can't be confirmed, the output now includes context like "likely v3.4 or v3.5" to explain why we couldn't determine the exact version.

I'm opening an issue to track improving the scanner messaging and will submit these changes as a PR shortly.

Originally posted by @jasonacox in #669 (reply in thread)