Remove (or dial down) blob-send diagnostic warn logging once send-starvation is diagnosed

Follow-up to #591 (blob-send warn visibility).

#591 adds throttled warn-level logging for the silent paths in `sendBlobs()` (park-on-cap, unpark-after-park, declined sends) specifically to diagnose a rare field failure: a deploy payload blob's content frames not going out for 60+ seconds while the replication connection is healthy and no shutdown drain is active (observed once on 5.1.19, 2026-07-16; peer's 20s `blobReadTimeout` failed the deploy; content flowed immediately after a fresh connection). Suspects: send parked on the per-connection `outstandingBlobsBeingSent` cap behind a stuck predecessor, or event-loop starvation on a single-worker origin during the deploy install phase.

The plan is to cherry-pick #591 into the next 5.1.x patch as a diagnostic lens. **Once the starvation is caught and root-caused (or the warns prove noisy/uninformative), revisit this logging**: remove it, reduce it to debug, or keep a slimmed-down version — whichever the diagnosis supports. This issue exists so the diagnostic instrumentation doesn't silently become permanent complexity.

Done when:
- The send-starvation trigger is root-caused (link the finding/issue here), and
- The #591 instrumentation is removed / demoted / consciously kept, with the decision recorded here.

— Claude (Opus 4.8), on behalf of Kris

Review #591 and the sendBlobs() paths for park-on-cap, unpark-after-park, and declined sends; use the field failure described here to identify the starvation trigger. Done means linking the root-cause finding and recording whether that instrumentation is removed, demoted to debug, or deliberately retained.

Written by the indexing model from the issue text.