Reject non-finite input in hash_rate_to_target

Summary

channels_sv2::target::hash_rate_to_target accepts non-finite arguments
(NaN, ±infinity) and silently produces a garbage target instead of
returning an error. For a +inf hashrate the garbage target is the hardest
the function can emit — it drives difficulty to the ceiling. This PR rejects
non-finite input up front with a dedicated error variant. It is a pure
input-validation fix: no behavioral change to any caller's control path.

The bug, and why +inf is the dangerous one

The function guards only three cases today:

if share_per_min == 0.0 { return Err(DivisionByZero); }
if share_per_min.is_sign_negative() { return Err(NegativeInput); }
if hashrate.is_sign_negative() { return Err(NegativeInput); }

None of these screen for finiteness, and the intermediate cast saturates
silently:

let h_times_s = hashrate * shares_occurrency_frequence;
let h_times_s = h_times_s as u128;   // NaN -> 0, +inf -> u128::MAX

So a non-finite argument slips past every guard and reaches the target
arithmetic. The three non-finite hashrate inputs resolve as:

The easy cases (NaN, 0.0) are self-correcting — an over-easy target makes
the miner over-produce shares and the controller tightens back up. The +inf
case is not. It silently emits the maximally over-difficult target — the
over-difficulty direction — from a converter whose contract is to reject bad
input. A miner whose telemetry reports +inf hashrate (a divide-by-zero in a
hashrate estimate, an overflow, an uninitialized sensor) would be handed the
tightest possible difficulty with no error raised anywhere. That is the failure
worth closing at the source: a single non-finite input driving difficulty to the
ceiling.

The fix

Reject non-finite hashrate and share_per_min before any arithmetic, with
a dedicated variant:

if !hashrate.is_finite() || !share_per_min.is_finite() {
    return Err(HashRateToTargetError::NonFiniteInput);
}

Two details that matter:

• Both operands are screened. A non-finite share_per_min reaches the same
  saturating cast path (60.0 / share_per_min then into the work term), so
  screening only the hashrate would leave the symmetric hole open.
• The check is ordered first, and the order is load-bearing. A NaN
  compares false to 0.0 and is sign-positive, so it would fall through the
  existing == 0.0 and is_sign_negative() checks to the cast; a -inf is
  sign-negative and would be mis-reported as NegativeInput. Putting the finite
  screen ahead of the others is what makes the rejection correct and the error
  variant accurate. A test pins this ordering.

A new HashRateToTargetError::NonFiniteInput variant (rather than overloading
NegativeInput) keeps the fault honest for callers: "you passed NaN" is a
different error than "you passed a negative number."

Tests

6 unit tests in target.rs (the function had no test module previously):

• non_finite_hashrate_is_rejected — NaN/+inf/-inf hashrate → NonFiniteInput
• non_finite_share_per_min_is_rejected — same for share_per_min (both operands)
• neg_infinity_is_non_finite_not_negative — the load-bearing ordering: -inf
  and a NaN share_per_min are reported NonFiniteInput, not NegativeInput
  / DivisionByZero
• positive_infinity_hashrate_does_not_yield_a_target — the headline case: a
  +inf hashrate no longer produces the hardest-difficulty target
• finite_input_still_converts / preexisting_finite_guards_unchanged —
  regression guards: ordinary finite conversion still works, zero hashrate is
  still accepted, and the pre-existing NegativeInput / DivisionByZero guards
  are unchanged

Scope

• One file: sv2/channels-sv2/src/target.rs (+~20 lines of fix, the rest
  tests). No other crate consumes HashRateToTargetError by exhaustive match,
  so the added variant is non-breaking.
• Input validation only — no behavioral/policy change. This does not alter
  how any controller responds to a valid hint; it rejects inputs that were
  never valid. (Hint-handling policy — how a consumer should react to a
  difficulty revision — is a separate concern and deliberately out of scope here.)