Keep Gantry provider records fresh and reject stale DHT hits

[Vaibhav Patel (vpatelsj)]

Why

Gantry provider records can outlive the peers that advertised them. During node replacement, stale records can dominate a lookup result and make cold-start or the final origin-fallback recheck look successful even though none of the returned peers can serve the digest.

At the same time, Gantry was publishing newly observed content without a periodic reprovide schedule, so a live provider could eventually disappear from discovery while still holding the content.

What changed

• Set provider-record validity to 6 hours and add a sweeping reprovide cycle every 3 hours, with up to 10 minutes of schedule delay.
• Register successful publications with libp2p's sweeping provider and stop scheduling them when containerd no longer holds the digest.
• Treat DHT records as candidates during chair polling and the NF5 recheck. A provider now has to answer a bounded metadata HEAD before it can count as usable.
• Remember failed chair-poll candidates for the current resolution so repeated stale results are not probed repeatedly. A chair that still reports progress can be retried at the same identity and address after it finishes.
• Keep request-scoped registry credentials out of metadata probes.

The sweeping schedule is intentionally in memory. Startup inventory reconciliation rebuilds it after a Gantry restart.

This does not change the DHT's 20-provider result limit or add a hard cold-start deadline; those remain separate follow-up work.