fix: keep enriching provider records past stale ones

[lidel]

This PR brings ipfs-check closer to how real world Kubo provider lookup looks like during retrieval. cc @aschmahmann as he noticed https://check.ipfs.network/ being flaky with /ipns/ipfs.tech (which has high drive-by provider churn).

Problem

Provider records returned by the DHT often arrive without addresses. For CIDs with high provider churn like /ipns/ipfs.tech, the previous 10-record cap was exhausted by stale records before any usable provider arrived. Even when the routing layer did return one, each per-provider probe ran on a fresh libp2p host with an empty peerstore, so addresses the daemon had already learned for that peer were ignored.

Solution

Keep the same record-arrival behavior, but stop counting address-less records against the soft cap, drain longer, let FindPeer enrichment run on the full request context, and seed each bitswap dial with addresses the daemon already knows for the peer.

Details

Commit 90bd607 (soft/hard caps + UI hint)

• daemon.go: split the per-provider worker into checkProvider; stream with count=0 from both DHT and IPNI; soft cap of 20 counts only providers that resolved at least one usable multiaddr; hard cap of 40 bounds total attempts. 20 is sized for how many providers Kubo's bitswap accumulates across a real retrieval (10 per provider-search round, several rounds per session).
• web/script.js: when every returned record lacks a multiaddr, show a hint that records are likely stale and point at Backend Config.
• CHANGELOG.md: documents the UI hint and the soft/hard cap behavior.

Commit 7f8dab3 (peerstore-seeded dials, longer timeout)

• checkProvider seeds each bitswap dial with addresses the daemon's main host already holds for the target peer, on top of record-supplied addrs and any FindPeer fallback. Mirrors how Kubo's bitswap dials.
• The probe host stays per-provider. Sharing one host across the request's concurrent probes is unsafe because vole.CheckBitswapCID installs a bitswap stream handler via host.SetStreamHandler, which replaces any prior handler, so a shared host would route every probe's responses to whichever receiver was registered last and the others' messages would fail the sender-vs-target check inside bsReceiver.
• Bitswap dial timeout raised from 15s to 30s so more NAT hole-punches and relay setups have time to complete, simulating real-world Kubo behavior.
• web/script.js: the "records likely stale" hint now requires at least one returned record, so it does not fire when the routing layer returned nothing at all.

Difference

Before	After (This PR)

Smoke test on a cold local ipfs-check backend daemon for /ipns/ipfs.tech (accelerated DHT off):

	Before (main)	After (this PR)
Attempted records	5	40
With at least one address	0	12
Bitswap.Found=true	0	2

Production with the accelerated DHT warmed up should do better.

Should we revisit other places?

Namely, does Kubo fail on /ipns/ipfs.tech? I think No.
I ran two fresh Kubo nodes and got identical results:

Config	findprovs	ipfs ls /ipns/ipfs.tech
Default (Routing.Type=auto, autoconf on)	20 providers	success in 2.3s
DHT-only (Routing.Type=dht, no delegated)	20 providers	success in 4.7s

Both Kubo runs effectively retrieve over the DHT for this CID. cid.contact returns 404. The DHT-only run had no delegated routers at all and still succeeded. The retrieval gap is therefore specific to ipfs-check, not the routing layer. It came from the cold per-probe host and the early cap on records, both of which this PR fixes.

[github-actions]

🚀 Build Preview on IPFS ready

• 🔎 Commit: 905001b
• 🔏 CID bafybeid5c4tdewmzwv467jremfd6divgq7rorzmbe774cp45oyarmnfzne
• 📦 Preview:

  • dweb.link

  • inbrowser.link