fix: use upstream_addr for routing PUT responses in NAT scenarios

[sanity]

Problem

The test_put_contract_three_hop_returns_response and test_three_node_network_connectivity tests were flaky, timing out intermittently on CI. Investigation revealed that PUT responses were failing to route back through intermediate hops in NAT scenarios.

Root Cause

The build_op_result function in put.rs used msg.target_addr() to determine where to route response messages. However, in NAT scenarios, target_addr() returns None because peers behind NAT don't know their external addresses - their PeerKeyLocation has an unknown socket address.

When target_addr is None, the response has no destination and silently fails to route, causing the test to time out waiting for a response that will never arrive.

Why Tests Were Flaky (Not Always Failing)

The tests simulated NAT scenarios using mock connections where addresses may or may not be fully resolved depending on timing and connection establishment order. When the address happened to be known, the test passed; when unknown, it timed out.

This Solution

The fix is a one-line change: prefer upstream_addr over msg.target_addr() for routing:

// Before: 
let target_addr = msg.as_ref().and_then(|m| m.target_addr());

// After:
let target_addr = upstream_addr.or_else(|| msg.as_ref().and_then(|m| m.target_addr()));

upstream_addr is the actual connection address from which we received the message - it's always available when we need to send a response back. This ensures responses route correctly even when the peer's address isn't recorded in the message metadata.

Testing

• Unit tests pass locally: cargo test -p freenet --lib
• The specific flaky tests should now be reliable

[AI-assisted - Claude]