fix(load): release completion handle when the response future resolves to Err

[ameyypawar]

Summary

Fixes #858.

TrackCompletionFuture::poll only took the load-tracking Handle on the success path:

let rsp = ready!(this.future.poll(cx))?;   // `?` returns early on Err
let h = this.handle.take().expect("handle");

When the inner response future resolved to Err, ? returned before handle.take() ran, so the Handle stayed alive until the outer future object was dropped rather than when the request actually completed. Both PendingRequests and PeakEwma track load through this Handle's Drop, so a failed request kept counting as pending — and, for PeakEwma, delayed its RTT sample — until drop time. Callers that hold onto completed error futures (logging, retries, batching) can therefore make an endpoint look busier or slower than it really is.

Fix

Match on the polled result and release the handle on both branches:

match ready!(this.future.poll(cx)) {
    Ok(rsp) => {
        let h = this.handle.take().expect("handle");
        Poll::Ready(Ok(this.completion.track_completion(h, rsp)))
    }
    Err(err) => {
        drop(this.handle.take().expect("handle"));
        Poll::Ready(Err(err))
    }
}

The success path is unchanged (the Ok arm is identical to the previous two lines); only the error path's timing changes — the handle is now released as soon as the response future resolves, regardless of outcome. This single change fixes both PendingRequests and PeakEwma, since both route their futures through TrackCompletionFuture.

Dropping the handle (rather than forwarding it) is the only option on the error path: TrackCompletion::track_completion(&self, handle, value: V) requires the success value V, which doesn't exist on Err. A handle can therefore only ever be forwarded into a successful response; on error, the RAII Drop is the intended completion signal.

One thing worth a maintainer's eye: as before, PeakEwma records an RTT sample for failed requests when the handle drops — this PR only corrects when that happens (at response completion instead of at future-drop). If folding failed-request latencies into the EWMA is undesirable, that's a separate change.

Tests

Adds a PendingRequests regression test (failed_response_completes_immediately) asserting that load returns to Count(0) as soon as the failed response future resolves, while the future is still held. It fails before this change and passes after.