channels_sv2: clamp target to max_target instead of erroring

[vnprc]

Problem

When a pool's vardiff computes a target easier than the client's declared
max_target, update_channel() returns Err(RequestedMaxTargetOutOfRange).
This silently breaks vardiff for the affected channel: the error is swallowed by
the caller, no difficulty update is applied, and the miner is permanently stuck
at its last successfully-set difficulty. The pool logs a WARN roughly every
60 seconds per affected channel while mining continues at the wrong difficulty.

This is not a hypothetical edge case. It triggers reliably for low-hashrate
miners whose natural vardiff target overshoots their declared max_target.

Root Cause

The max_target field in OpenExtendedMiningChannel means "the easiest
difficulty I will accept." When vardiff computes a target easier than
max_target, the correct response is to assign exactly max_target — the
client has already declared that difficulty acceptable. The current code errors
instead, which is both incorrect per the spec and operationally harmful.

Fix

Replace the RequestedMaxTargetOutOfRange error path with a clamp in four
places:

• ExtendedChannel::new() — channel creation
• ExtendedChannel::update_channel() — vardiff updates
• StandardChannel::new() — channel creation
• StandardChannel::update_channel() — vardiff updates

Also removes two stray println! debug statements from ExtendedChannel::new().

Tests

The existing test_update_channel tests in both extended.rs and standard.rs
already exercise this path (very_small_hashrate = 0.1). They previously
asserted is_err() / RequestedMaxTargetOutOfRange. They now assert is_ok()
and verify the channel target was clamped to not_so_permissive_max_target.
All 50 unit tests pass.

Notes

• RequestedMaxTargetOutOfRange is preserved in both error enums — it remains
  reachable from the UpdateChannel message handler path where the client itself
  sends a bad max_target.
• No API surface changes (no new public types, no signature changes).

Pre-existing CI failure

cargo clippy currently fails on upstream main due to needless_lifetimes in
binary_sv2 — unrelated to this PR.

---

companion stratum-mining/sv2-apps#447

[Alkamal01]

Tested this locally and the math checks out. Moving from an error to a clamp in update_channel is the right move for vardiff—it stops the lock-up for smaller miners without touching the high-end.

I did a quick check on the f64 limits too. Since the clamp is unidirectional (target>max_target), it won't trigger for high-hashrate ASICs, so no new precision loss there. Also, good call on dropping those println! calls in the constructor; we don't need the I/O lag in high-concurrency.

All 50 channels_sv2 tests passed. Concept is solid. LGTM.

[vnprc]

Thanks for looking at this @Alkamal01!

[plebhash]

thanks for spotting this @vnprc

apologies for taking so long to review it, this is a great improvement!

overall the PR is pretty solid, but there's a few things left... I'm taking the liberty of implementing them to make the review cycles a bit more agile, can you rebase against main and cherry pick these commits from my fork here?

• 4894c98
• bde2a2e
• 19b6c86

[plebhash]

can you rebase against main and cherry pick these commits from my fork here?

actually nevermind @vnprc , I just realized I'm able to push here

[vnprc]

awesome! thanks for looking at it! lmk if i can help in any way.