fix(wifi): read neighbour scan strength as dBm, not the raw quality index

[drench44]

The bug

stat/rogueap reports neighbour strength two ways:

• signal is the real RSSI in dBm (negative)
• rssi is the driver's 0-based quality index above the noise floor (positive, roughly 2..50 in practice)

ingest/unifi/models.py already documents exactly that distinction on the mesh-uplink fields, but RogueAp dropped signal entirely and the shared neighbour decoder passed the index straight through as "rssi".

Both wifi.neighbor_density and wifi.rogue_ap then compare that value against a *_rssi_floor_dbm threshold. A positive number is never <= -75, so the "strong enough to matter" filter never excluded anything and every audible BSS qualified.

On my own store that reported 258 of 265 scanned networks as crowding the 2.4 GHz channels, in a neighbourhood nowhere near that dense. All 619 neighbour rows carried positive values, range 2 to 49, not one negative. The count above the real -75 dBm line is 14.

The fix

Convert once in _neighbor_rows, the shared decoder both detectors already read through, so the two cannot disagree about what the scan said.

• Prefer signal when the poll captured it
• Fall back to the index offset by the noise floor for rows collected before it did
• The offset is tunable as noise_floor_dbm under wifi.neighbor_density, read from that one key by the shared decoder because it describes the scan, not either detector's policy
• Capture and persist signal on RogueAp so new scans carry exact dBm rather than an offset estimate

Sign alone does not prove a field is dBm. Drivers use small negative sentinels for "no reading", and this module already carries or -127.0 fallbacks for that case. A -1 taken verbatim would read as an absurdly strong neighbour that clears every floor and silently inflates the count, so both branches require a plausible sighting (-120..-20 dBm) and treat anything else as junk.

Verification

Full suite: 2002 passed, 1 skipped.

New tests cover the index reading as dBm, a genuinely strong index still counting, signal winning when both are present, noise_floor_dbm reaching the decoder end to end, and the sentinel cases (-1, -400, a negative index) being rejected rather than trusted.

Replayed against a real 619-row store, the 2.4 GHz finding goes from 258 qualifying to 14:

Stronger than	Count
-65 dBm	3
-70 dBm	5
-75 dBm (the floor)	14
-80 dBm	28

The 5 GHz finding falls below density_min_count and clears. Top-offender ordering is unchanged and the values are now real dBm.

Known gap, not addressed here

A finding's rssi_dbm evidence does not say whether it came from a measured signal or an offset index. On a mixed-vintage store those are indistinguishable, and the estimated ones move if noise_floor_dbm is retuned. An rssi_source field would fix it; happy to add if you want it in this PR.

[gneitzke]

Thanks @drench44, great catch. Reading the quality index as dBm was quietly inflating the neighbour count — I'd been seeing "123 neighbouring networks" on my own 2.4 GHz during a UI pass, and this is exactly why. Converting once at the boundary (with the noise-floor guard so the two detectors can't disagree) is the right call, and the test coverage is appreciated. Pinning it into the next release now.