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.