rust-v0.53 WebRTC-direct connection timeout

Nobody has claimed this yet.

**Repo:** [libp2p/rust-libp2p](https://github.com/libp2p/rust-libp2p)
**Source:** local build (`images/rust/v0.53`, based on commit `b7914e407da34c99fb76dcc300b3d44b9af97fac`)
**Transport:** webrtc-direct

## Summary

rust-v0.53 times out when establishing WebRTC-direct connections with go-v0.38 (as native dialer) and with rust-v0.53 itself (as WASM/Chromium dialer). Both containers start and connect to Redis via the proxy, but no WebRTC connection is ever established. The tests hit the 180-second timeout with no output from either the dialer or listener beyond initial startup.

## Failing tests (2)

- `rust-v0.53 x go-v0.38 (webrtc-direct)` — rust-v0.53 native dials go-v0.38
- `chromium-rust-v0.53 x rust-v0.53 (webrtc-direct)` — rust-v0.53 WASM (Chromium) dials rust-v0.53 native

## Error output

Both tests show identical behavior — timeout with no connection:

```
proxy | redis-proxy: listening on :6379, upstream=transport-redis:6379, test_key=b29a1a36
proxy | redis-proxy: new connection from 172.18.0.5:37462
listener | My multiaddr is: [/ip4/172.18.0.5/udp/46178/webrtc-direct/certhash/uEiBR1dWw...]
proxy | redis-proxy: new connection from 172.18.0.6:49296

[180 seconds of silence]

ERROR: ✗ Test timed out after 180s
```

The go listener publishes its multiaddr. The rust dialer connects to the proxy. But no WebRTC signaling or connection attempt appears in the logs.

## Root cause analysis

This is distinct from the `rust-v056-webrtc-direct-srtp-panic.md` bug (which is a SRTP key derivation crash in v0.56). Here, rust-v0.53 simply never initiates the WebRTC connection.

Possible causes:
- rust-v0.53's WebRTC-direct dialer may fail to parse the listener's multiaddr from Redis (legacy key format through proxy)
- The ICE candidate exchange may fail silently in the legacy Redis key translation
- The WASM (Chromium) build may have additional WebRTC API limitations

Note that rust-v0.53 is a legacy implementation connecting through the Redis proxy. The WebRTC-direct multiaddr includes a certhash component which the dialer must retrieve from Redis to initiate the connection. If the proxy's key translation loses or corrupts the certhash data, the dialer would silently fail to connect.

## Notes

- rust-v0.53 is `legacy: true` and uses the Redis proxy for coordination
- Other rust-v0.53 webrtc-direct tests may also fail but were not included in this filtered test run
- The go-v0.38 listener starts correctly and publishes its multiaddr — the issue is on the dialer side
- No proxy hostname issues — correct `proxy-` format used

Start with the legacy implementation under images/rust/v0.53 and trace the Redis proxy coordination used by the two failing tests: rust-v0.53 x go-v0.38 and chromium-rust-v0.53 x rust-v0.53. Check how the listener multiaddr and certhash move through the proxy; done means both tests establish WebRTC-direct connections without timing out.

Written by the indexing model from the issue text.