fix: data race on AddrInfo.Addrs in queryPeer

[lidel]

The race

findProvidersAsyncRoutine (and the GetValue / FindPeer) hand the same []*peer.AddrInfo to two places:

1. routing.QueryEvent.Responses, observed by any RegisterForQueryEvents subscriber (e.g. handlers that json.Marshal the event).
2. queryPeer in query.go, which did next.Addrs = append(next.Addrs, ...).

Two goroutines end up writing and reading the same AddrInfo.Addrs slice header. Under -race the detector flags the conflict; without -race, a torn slice header can crash inside go-multiaddr when the consumer walks Addrs.

Refs: ipfs/kubo#11287, ipfs/kubo#11116

The fix

Note

This class of errors could be fixed by upstream libp2p/go-libp2p#3490, but I also believe we should do this PR (belt-and-suspenders) so we don't wait for go-libp2p release or are hit by a future refactor there.

In queryPeer, build a fresh slice with slices.Concat(next.Addrs, curInfo.Addrs) instead of mutating next.Addrs. The combined addresses are passed to queryPeerFilter and maybeAddAddrs; the published *peer.AddrInfo is no longer touched.

slices.Concat is preferred over append: with spare capacity, append would reuse next.Addrs's backing array, which the consumer still references. slices.Concat always allocates a fresh array, so no memory is shared with the published event.

Also documents the read-only contract on the queryFn type so LLMs and humans avoid introducing regressions that mutate.

Tests

• New TestFindProvidersAsyncQueryEventResponsesRace drives real FindProvidersAsync against an intercepted protoMessenger.
  • Fails on master under -race,
  • passes on this branch.
• Full package suite passes under -race.

[guillaumemichel]

Great finding @lidel! Thanks for the fix and informative regression test!