Caller-supplied net.Addr implementations are trusted and can cause side-effect DoS

```json
[
  {
    "severity": "high",
    "title": "Pending dial holds listener mutex and can deadlock Close",
    "function": "DialWithLocalAddr",
    "description": "DialWithLocalAddr acquires ln.lock, sends the server-side connection to ln.conns, then blocks on <-accepted while still holding ln.lock. If the acceptor is absent, delayed, or blocked, the Dial call never returns. Close also requires ln.lock, so closing the listener deadlocks behind the pending dial. This can leak the dial goroutine, the PipeConns pair, and the accepted channel, and can freeze all further Dial calls. A caller can trigger this by invoking Dial without an active Accept loop or with an acceptor that never consumes the queued connection."
  },
  {
    "severity": "low",
    "title": "Dial creates a client connection with a nil local address",
    "function": "Dial",
    "description": "Dial hard-codes local to nil and passes it to DialWithLocalAddr, which stores nil as the client-side local address. Generic net.Conn consumers often call conn.LocalAddr().Network() or conn.LocalAddr().String() without a nil check, so using the returned connection in such code can panic. This is reachable through the exported Dial API and any code path that uses the returned connection's local address."
  },
  {
    "severity": "low",
    "title": "Caller-supplied net.Addr implementations are trusted and can cause side-effect DoS",
    "function": "SetLocalAddr",
    "description": "SetLocalAddr stores an arbitrary caller-supplied net.Addr, and Addr/DialWithLocalAddr expose it to other code. If a hostile or buggy net.Addr implementation performs expensive, blocking, or unsafe work in Network()/String(), invoking those methods on the listener or connection addresses can cause denial of service or unexpected behavior. The library performs no validation, isolation, or thread-safety checks on the address implementation."
  }
]
```