datastorage: use RCPI when probe signal is unavailable

[gchmurka123]

Summary

Use beacon-report RCPI as an RSSI fallback when scoring a probe entry whose
signal field is zero.

The change is intentionally limited to eval_probe_metric():

• a non-zero signal continues to be scored exactly as before;
• when signal == 0 and RCPI is in the valid IEEE 802.11 range 0..220, RCPI
  is converted with the existing rcpi_to_rssi() helper;
• RCPI values above 220 are not used and the entry remains unscored;
• the converted value is used by the existing stepped and graduated RSSI
  scoring calculations without changing their configuration or semantics.

Problem

Beacon reports can populate a probe entry with a valid rcpi while leaving
signal at zero. The current implementation only enters the AP scoring path
when probe_entry->signal != 0.

As a result, an AP reported by the client can receive a score of zero even when
the beacon report contains usable signal-quality information. In a dual-band
deployment this can prevent a valid 5 GHz AP from becoming a steering candidate,
leaving the client on 2.4 GHz despite a good reported 5 GHz signal.

There is already a TODO in this function asking whether RCPI should be used.
DAWN also already provides rcpi_to_rssi(), so the conversion does not need to
be duplicated.

Implementation

The patch copies probe_entry->signal into a local signal variable and tracks
whether a usable value is available. If the original signal is unavailable but
RCPI is valid, it converts RCPI to dBm and runs the existing scoring code with
that result.

This is a fallback, not a second score source. When both values are present,
the original non-zero signal remains authoritative and RCPI is ignored.

A trace message is emitted when the fallback is used:

Scoring beacon report using RCPI <value> as signal <value> dBm

Behaviour before and after

Before:

signal == 0, valid RCPI present -> AP score remains 0

After:

signal != 0                    -> unchanged RSSI scoring
signal == 0, RCPI in 0..220    -> score using rcpi_to_rssi(RCPI)
signal == 0, RCPI above 220    -> AP remains unscored

Testing

• Built successfully for aarch64_cortex-a53 using the official OpenWrt
  25.12.5 mediatek/filogic SDK.
• Tested on two D-Link AQUILA PRO AI M60 A1 access points running OpenWrt
  25.12.5.
• Confirmed that ordinary entries with a non-zero signal retain their
  existing scoring behaviour.
• Confirmed the fallback at runtime with beacon-report-only entries:

RCPI	Converted RSSI
52	-84 dBm
78	-71 dBm
158	-31 dBm

• Confirmed that the converted RSSI feeds the existing AP score and allows the
  reported 5 GHz AP to participate in candidate comparison.
• Confirmed successful 802.11v BSS transition handling in the test deployment.

Scope and compatibility

No UCI options or defaults are changed. No new scoring mechanism is introduced.
Deployments that already provide a non-zero probe signal retain the previous
behaviour. The fallback only affects entries that would otherwise skip RSSI and
AP scoring entirely despite carrying a valid RCPI value.

[PolynomialDivision]

Looks good to me