fix: derive device MAC from BLE local name on EU/NA v2 API

[rencsaridogan]

Problem

On the EU/NA v2 API, omron list / device discovery returns no devices even when the OMRON account has active, registered devices. The account authenticates fine; the device list just comes back empty.

Root cause

OmronConnect2.get_registered_devices reads the MAC only from attributes.macAddress:

macAddress = attrs.get("macAddress", "").strip()
if not macAddress:
    L.debug(f"Skipping device without MAC address: ...")
    continue

The EU/NA v2 init-user response does not include a macAddress field. The MAC is instead encoded in the BLE local name, e.g.:

"deviceLocalName": "blesmart_0001020828ffb210aaa4"   ->  28:FF:B2:10:AA:A4
"deviceSerialID":  "<serial>"

So every device hit the continue guard and was silently dropped.

Fix

Before giving up, fall back to deriving the MAC from the BLE local name (last 12 hex chars), then from deviceSerialID via the existing serial_to_mac:

• New helper ble_local_name_to_mac() mirrors the exact derivation already used by omramin.omron_ble_scan (last 12 hex of the BLEsmart_ name), so the resulting MAC is identical to what BLE discovery and manual add --macaddr produce.
• v2 discovery order: macAddress -> BLE local name -> deviceSerialID.

The MAC is only used as a config identifier (v2 matches measurements by userNumberInDevice, not MAC), so this restores discovery without affecting sync matching.

Verification

On an EU (NL) account whose v2 response omitted macAddress:

• Before: omron list -> "No devices found in OMRON Connect"
• After: omron list -> device found with MAC 28:FF:B2:10:AA:A4, and sync transfers weigh-ins to Garmin end-to-end.

Additionally, the real get_registered_devices code path was driven with canned
EU/NA v2 responses (offline, no credentials) alongside helper unit checks — 9/9 passed:

• ble_local_name_to_mac("blesmart_0001020828ffb210aaa4") -> 28:FF:B2:10:AA:A4, identical to the rule in omramin.omron_ble_scan (last 12 hex, uppercase)
• Helper rejects empty / too-short / non-hex local names (returns "")
• get_registered_devices now discovers a device whose v2 attributes have no macAddress (previously dropped by the skip-guard)
• No regression: when macAddress is present it is used unchanged
• Falls back to serial_to_mac(deviceSerialID) when neither macAddress nor a usable local name is present
• Inactive devices (isActive: 0) are still skipped
• Module imports cleanly
• Live end-to-end on an EU (NL) account: omron list found the device and sync transferred weigh-ins to Garmin Connect

[rencsaridogan]

Reviewed the discovery change. The approach is sound: v2 matches measurements by userNumberInDevice, so deriving the MAC purely as a stable config identifier is safe, and reusing the omron_ble_scan last-12-hex rule keeps it consistent with BLE discovery and manual add --macaddr. Two non-blocking notes inline.

Unrelated drive-by noticed while reading (not part of this PR): the v2 unknown-category branch logs device.get('deviceModel'), but in the v2 loop deviceModel lives under attributes (attrs), so that warning always prints None. Pre-existing — mentioning since it's nearby.

[rencsaridogan]

Review feedback addressed in f39fff1:

• MAC case consistency — the resolved MAC is now uppercased once after the fallback chain, so the API macAddress, BLE-local-name, and serial_to_mac paths all agree. ✅ resolved
• Prefix guard — ble_local_name_to_mac now requires a BLESMART_ prefix before deriving. ✅ resolved
• Drive-by (v2 unknown-category log) — now logs the inferred deviceModel instead of device.get('deviceModel') (which was always None in the v2 loop). ✅ fixed

Re-verified against the real get_registered_devices path with canned v2 responses — 11/11 checks pass, now including: non-BLESMART_ names rejected, lowercase API macAddress normalized to uppercase, and serial fallback normalized to uppercase.