Clean up PUT direct-ack shortcut

[sanity]

Summary

The PUT pipeline currently emits a second SuccessfulPut directly to the operation originator (see PutOp::process_message in crates/core/src/operations/put.rs). This extra ACK works around the fact that the normal upstream response path can drop messages when transport tasks stall. Now that we're instrumenting and fixing the actual transport issue, this shortcut is both redundant and risky: it can hide missing responses and complicates reasoning about message delivery.

Why this matters

• It papers over bugs higher up in the stack instead of fixing them.
• We end up with duplicate SuccessfulPut logs that make debugging harder.
• Long-term, it can mask regressions in transport or routing because the client still receives the direct ACK even if the main path is broken.

Proposal

1. Remove the direct-send block inside PutOp::process_message (both the broadcast and final-hop cases).
2. Audit tests to ensure they don't rely on the shortcut.
3. Confirm that the standard upstream path is exercised by running the flaky PUT/connectivity tests with trace logging after the listener fix lands.

Tracking this cleanup separately keeps PR #2064 focused on stabilizing transport while ensuring we don’t carry the workaround forward.

[github-actions]

🤖 Auto-labeled

Applied labels:

• T-enhancement (95% confidence)
• E-medium (80% confidence)
• A-networking (90% confidence)
• A-developer-xp (80% confidence)

Reasoning: The issue proposes removing a redundant direct-ack shortcut in the PUT pipeline and auditing tests — this is an improvement/cleanup rather than a bug report or new feature, so T-enhancement fits. Changes touch transport/upstream message delivery and test behavior, so A-networking and A-developer-xp are relevant. Estimated effort is medium because it requires code changes and test updates and verification with flaky tests and transport fixes.

Previous labels: none

If these labels are incorrect, please update them. This helps improve the auto-labeling system.