persist: make Pending cancel safe

[antiguru]

Pending::block_until_ready replaced the state with a Blocking placeholder before awaiting the write handle. Dropping the future at that await left the placeholder in place permanently, and every later into_result on that Pending panicked with "block_until_ready cancelled?".

BatchBuilder reaches that await in its ordinary write path, in the loop that bounds outstanding part writes, and finish reaches into_result through the run-completion paths. A caller who drove BatchBuilder::add inside a cancellable future and then called finish, for example to obtain a Batch it could delete(), hit an unconditional panic. Since install_enhanced_handler aborts the process for any panic outside a catch, that lost the whole process rather than the batch. The window is not narrow: for a large batch on object storage the part writes are the bottleneck, so a builder past a few parts spends most of its wall time inside exactly that await.

The fix awaits the handle through the borrow instead of taking it out. Nothing is removed from the state, so there is no placeholder to leave behind and the Blocking variant disappears along with its panic. The spawned task keeps running across the cancellation, so a later block_until_ready or into_result still yields the value.

Two items from PER-70 stay open and are not part of this change: a BatchBuilder teardown that surrenders the parts already written without flushing the buffered one, and removing the ore_catch_unwind workaround that #38482 wraps around its peek-stash blob cleanup, which this fix makes unnecessary.

Adds test_pending_survives_cancellation, which cancels a block_until_ready at its await point and then reads the value; it fails with the original panic before the fix.

Closes: PER-70

🤖 Generated with Claude Code

[antiguru]

Thanks for the review!