Bug: LuxMiner hashrate uses chain_rate which diverges from GHS 5s

[wilfredallyn]

Note: This fix depends on #410 landing first. Without it, _get_hashrate() is unreachable so raw_hashrate never gets set, and the fallback won't work.

Problem

_get_hashboards() reads chain_rate{n} from LuxOS stats API to get per-hashboard hashrate. LuxOS docs say "Real hashrate, in GH/s, of the Xth hashchain," but I found that it matches avg hashrate (GHS av). When MinerData.hashrate sums these values, it doesn't get the correct hashrate. The correct value is in _get_hashrate() which reads GHS 5s from the summary API.

Evidence

Tested on S19K Pro running LuxOS 2025.3.6, preset 415MHz (~86 TH/s expected).

Raw summary API (echo '{"command":"summary"}' | nc $MINER_IP 4028):

  "GHS 5s": 87753.75    ← real-time (matches LuxOS dashboard: 86.92 TH/s)
  "GHS av": 54014.30

Raw stats API (echo '{"command":"stats"}' | nc $MINER_IP 4028):

  "chain_rate1": "18066.21"
  "chain_rate2": "18090.59"
  "chain_rate3": "17859.35"
  Sum: 54,016 GH/s      ← matches GHS av (54,014), NOT GHS 5s (87,754)

pyasic reported hashrate=54.0 TH/s while the miner was hashing at 87 TH/s according to LuxOS dashboard. I confirmed this value on mining pool dashboard.

Fix

Delete lines with chain_rate in _get_hashboards(). Without per-board hashrate values, MinerData.hashrate defaults to raw_hashrate which gets GHS 5s from _get_hashrate().