Fix KetamaHashing panic on zero-weight backend killing load balancer background task

[sinhaparth5]

Fixes #1006.

Root cause

KetamaHashing::build_with_config passes Backend::weight (an unvalidated usize) straight into pingora_ketama::Bucket::new, which asserts weight != 0 and panics otherwise. A ServiceDiscovery implementation that uses weight 0 as a draining marker, or a config/DNS typo, is enough to trigger it.

That call runs inside LoadBalancer::update(), called from the background update loop in background.rs with no catch_unwind or spawn_blocking around it. The newer LoadBalancerGroup rebuild path already guards the equivalent call with spawn_blocking and JoinError::is_panic(), but the plain LoadBalancer<S>::run() path does not. Once the panic fires, the update task ends and is never restarted: backend membership and health check state freeze permanently (or the whole process aborts, under panic = "abort"), from a single zero-weight entry in one discovery response.

Fix

Clamp the weight to a minimum of 1 at the point it crosses from Backend into Bucket, in KetamaHashing::build_with_config. This is the only place backend weights feed into pingora-ketama in this crate, so it is the right boundary to treat the value as untrusted input.

Testing

• Added test_ketama_zero_weight_backend_does_not_panic, which builds a KetamaHashing ring with a zero-weight backend and checks it is still reachable.
• Reproduced the panic on an isolated GCE VM (torn down afterward): built the parent commit with a #[should_panic] version of the same test and confirmed it panics with weight must be at least one; the fixed commit does not panic and the same test passes.
• cargo test -p pingora-load-balancing passes in full (79 tests) on the fixed commit.