lime-system: detect radios on any bus in wireless.scandevices()

[Pablomonte]

scandevices() filters out radios whose hardware is missing by globbing /sys/devices//ieee80211/phy*, but the path netifd stores in uci is relative to a bus prefix that varies per target. On ramips/mt7621 (LibreRouter R2)
the PCIe controller is a platform device: uci holds 1e140000.pcie/pci0000:00/... while sysfs exposes /sys/devices/platform/1e140000.pcie/.... The glob never matched, so the three ath9k radios of a LibreRouter v1 card were all
reported as hardware not found, lime-config generated no wifi-iface and the radios stayed disabled.

Instead of guessing the prefix, resolve each phy under /sys/class/ieee80211 with realpath(3) and match the uci path against it. This also covers the +N suffix netifd appends when several phys share one device (mt7915 DBDC).
Stale radios are still rejected — that is what keeps firstbootwizard from asking for a phy that does not exist and dying in get_phy_mac().
Tested on a LibreRouter R2 (LibreRouterOs 2025.10, kernel 6.6.121), three ath9k radios:

The second commit fixes tests/test_lime_config_device.lua (#librerouter), which is already red on final-release for the same root cause: the fixture's sysfs paths do not exist in the test container, so all three radios get filtered and no mesh interface is generated. Stubbing the phys makes it pass — 332 passing, 0 failures.

[Pablomonte]

Cerrada: la abrí desde la rama equivocada. El head era Pablomonte:master, que solo contiene dos commits de update de lime-app, y la base era master en lugar de final-release (donde vive el filtro de hardware que este fix corrige).

El fix real, con los commits correctos y el test suite en verde, está en #18.