perf(p2p): parallelize catalog peer lookups

[catyans]

Summary

• run Iroh catalog lookups with a fixed four-peer concurrency window
• preserve scheduler-provided candidate order when selecting a descriptor
• keep misses, timeouts, invalid endpoints, and self/local candidates compatible with the existing fallback behavior
• add deterministic coverage for ordering and the in-flight concurrency bound

Why

lookup_peers currently waits for every candidate serially. With the default
5-second per-peer timeout, stale peers at the front of the discovery result can
make lookup latency grow as N * lookup_timeout.

The new ordered buffer starts up to four lookups concurrently but consumes their
results in candidate order. This bounds connection fan-out and reduces timeout
accumulation without changing scheduler priority.

Lingjun validation

Validation was run on the four-node Lingjun cluster, not on the development
machine.

• cargo fmt --all -- --check
• new ordered-buffer tests: 2 passed
• p2p::iroh::transport::tests: 14 passed

Four-node latency experiment

• consumer: lingjun-099 (192.168.0.42)
• stale Iroh endpoints: lingjun-100 and lingjun-101
• valid provider: lingjun-102
• lookup timeout: 1000 ms
• candidate order: stale-100, stale-101, valid-102

All endpoints were produced by real IrohBlobsP2pTransport instances. The first
two providers were then stopped before measurement; the third continued serving
the published artifact.

implementation	five lookup samples (ms)	mean (ms)
current serial main	2028.327, 2029.424, 2028.062, 2026.525, 2026.695	2027.807
ordered concurrency window	1000.855, 1002.165, 1000.564, 1001.104, 1001.576	1001.253

The change reduced mean lookup latency by approximately 50.6%; all 10/10
lookups returned the descriptor from lingjun-102.

The branch was subsequently rebased onto v0.1.1 main; git range-diff
confirmed that all four patch commits remained identical.

Fixes #95

[github-actions]

🔍 OpenCodeReview found 1 issue(s) in this PR.

• ✅ Successfully posted inline: 1 comment(s)

[github-actions]

[test · low]
Bound these synchronization waits (and the barrier waits in the following test) with tokio::time::timeout(TEST_TIMEOUT, ...). If a regression prevents a candidate from being polled or changes the initial concurrency window, the test currently deadlocks indefinitely rather than producing an actionable failure; this file already defines TEST_TIMEOUT for that purpose.

Suggestion:

Suggested change

	first_started.notified().await;
	second_finished.notified().await;
	tokio::time::timeout(TEST_TIMEOUT, async {
	first_started.notified().await;
	second_finished.notified().await;
	})
	.await
	.expect("initial buffered lookups should complete");