test(e2e): NatProfile::PortRestrictedConeAutoNATOk variant

[pvg13]

Summary

Adds an AutoNAT-permissive NAT shape so libp2p's reachability-verification protocol can succeed inside the harness — closes the immediate "DCUtR doesn't fire because AutoNAT is blocked" finding from #50, surfaces a deeper finding that's now filed as #51.

Stacks on top of #50 (NAT-topology shapes); merge that first.

What's new

• `NatProfile::PortRestrictedConeAutoNATOk` — same as `PortRestrictedCone` but whitelists the AutoNAT server's bridge IP for unsolicited inbound. The relay also acts as the AutoNAT server in our setup (via `autonat::v2::server`), so the harness automatically passes the relay's bridge IP through.
• Harness resolves the relay's bridge IP via `ContainerAsync::get_bridge_ip_address()` after starting the relay, threads it through `apply_nat_to_container`.
• `dcutr_validation_cellular_fair` updated to use the new variant.

Empirical findings

Under `cellular_fair + PortRestrictedConeAutoNATOk`:

• ✅ Whitelist applied (`[harness] PortRestrictedConeAutoNATOk: whitelisting relay bridge IP 172.21.0.2`).
• ✅ AutoNAT now reports the peer's address as reachable (was "NOT reachable" under plain `PortRestrictedCone`). Engine sees Public NAT.
• ✅ Sync works end-to-end.
• ❌ But `dcutr_upgrades_attempted = 0` still.

Root cause traced: the relay introduces peers via `PeerList` / `PeerJoined` near-simultaneously, both peers fire dial-outs immediately, each side's outbound creates a conntrack entry, the other's inbound matches as ESTABLISHED — peers form a direct connection naturally without DCUtR's coordination.

This is realistic NAT behaviour (it's why hole-punching works on most home networks), but it's not useful for exercising DCUtR specifically. Forcing DCUtR requires a symmetric-NAT shape that rotates source ports per-destination so simultaneous dial can't catch the same flow tuple. Filed as #51.

What lands here, what doesn't

✅ `PortRestrictedConeAutoNATOk` is useful infrastructure independent of the DCUtR question — any future bench that wants AutoNAT-verified peers behind realistic NAT can use it.

✅ The harness now correctly resolves and passes through container IPs at NAT-rule application time.

❌ DCUtR end-to-end validation still pending — needs #51 (symmetric NAT). The acceptance criterion 3 of #40 ("partition-recovery drops 30% on cellular_fair via DCUtR") therefore remains open until #51 lands.

Test plan

• `cargo build -p wavesyncdb-e2e --tests`
• `./tests-e2e/build-images.sh`
• `cargo test -p wavesyncdb-e2e --test dcutr_validation -- --ignored --nocapture` runs cleanly; output documents the new finding.
• AutoNAT-reachable status confirmed via container logs during validation runs.

Related

• Stacked on test(e2e): NAT-topology shapes via iptables (closes #42) #50 — NAT-topology shapes (PortRestrictedCone, base infra)
• Closes the immediate "AutoNAT blocked" finding from test(e2e): NAT-topology shapes via iptables (closes #42) #50
• Surfaces and files Test harness: add SymmetricNat shape (SNAT/DNAT-based) to actually exercise DCUtR #51 — SymmetricNat shape needed to actually exercise DCUtR
• Engine: enable DCUtR — upgrade circuit-relay paths to direct via hole-punching #40 — DCUtR upgrade circuit-relay → direct (acceptance extract_pk_from_where fails on quoted values with spaces #3 awaits Test harness: add SymmetricNat shape (SNAT/DNAT-based) to actually exercise DCUtR #51)