feat(ble): report Bluetooth 5 long-range advertisements as ble5

[wnagele]

What

Bluetooth 5 long-range / extended advertisements (a Message Pack per advertisement) are now received at all — previously they were dropped at the service-data length check and logged as "Unrecognised service data". They report through the existing rid_source field with a new value ble5; Bluetooth 4 legacy advertisements keep ble. No new field, no schema_version bump. Journal lines log as [BLE] / [BLE5], /status gains a ble5 per-source counter, and the dashboard, history DB and MQTT events/detection payload carry it through rid_source unchanged.

Why

ASTM F3411 defines two BLE transports: Bluetooth 4 legacy advertising carries one 25-byte ODID message per advertisement, while Bluetooth 5 long-range / extended advertising carries a Message Pack. Before this change, BT5 transmitters (ArduRemoteID, Dronetag, …) were invisible over BLE, and everything BLE reported as one undifferentiated ble — so a receiver that cannot hear Bluetooth 5 (a BT 4.x dongle, Pi onboard Bluetooth) was indistinguishable from empty airspace. With ble5 as a distinct value, a ble5 counter pinned at zero while ble climbs makes the adapter the visible limit. Consumers that pass rid_source through are unaffected; those that enumerate its values gain one.

How

• extract_rid_payload() now accepts pack payloads (service data longer than one message with the 0x0D app code) and decodes all sub-messages.
• Classification comes from the wire format, not the stack: a Message Pack cannot fit a legacy ADV PDU's 31-byte cap, so "pack" ⇒ Bluetooth 5 — necessary because BlueZ does not expose the PHY of received advertisements.
• The decoder passes "ble5" / "ble" into the tracker's existing rid_source path — the tracker, feed rows, /status counters and MQTT events needed no changes at all; only the BLE decoder and the dashboard's always-shown source tiles (KNOWN_SOURCES) plus FEED.md/README/CHANGELOG documentation.