Stop relying on filecoinpin.contact for indexing verification, use Curio piece-status endpoint instead

[BigLep]

Depends on: #664, curio#1405

Summary

filecoin-pin currently polls filecoinpin.contact directly (waitForIpniProviderResults in src/core/utils, exported via filecoin-pin/core/utils) to verify that uploaded content has been indexed and is discoverable. dealbot also consumes this same function today. We're migrating off filecoinpin.contact entirely (see #664), and the replacement logic belongs in filecoin-pin's library so both the CLI and dealbot get it from one place rather than each reimplementing it.

The new polling function does two things, in order:

1. Poll Curio, not an indexer. Poll Curio's GET /pdp/piece/{pieceCid}/status until it reports synced: true (curio#1405). This replaces today's direct polling of filecoinpin.contact's IPNI-compatible API.
2. Confirm against cid.contact. Once Curio reports synced, do one confirming query against cid.contact for the root CID (GET https://cid.contact/cid/{rootCid}). By this point it should already be indexed, so this shouldn't trigger cid.contact's negative cache — see [Tracking] Migrate FOC off filecoinpin.contact, use cid.contact only #664's "Intended solution" section for why this ordering matters.

We don't expect step 2 to ever fail once step 1 says synced, but if it does — Curio thinks cid.contact has indexed the content and cid.contact has no record — that's a real anomaly, not routine "still indexing" noise. The library needs to expose that specific case (Curio/cid.contact disagreement) as a distinct, identifiable error or event, separate from "not yet indexed" or "timed out," so callers can react to it deliberately rather than it getting lost inside a generic verification failure.

Steps

• Identify where filecoin-pin currently polls/queries filecoinpin.contact for indexing status (waitForIpniProviderResults and callers in src/core/).
• Replace that polling with calls to Curio's GET /pdp/piece/{pieceCid}/status endpoint, waiting for synced/syncedAt, once available (curio#1405).
• After synced, add the confirming cid.contact query for the root CID.
• Expose a distinct error/event when Curio reports synced but the cid.contact confirmation query doesn't find the CID (e.g. a dedicated error type or an emitted event distinguishable from "not yet indexed" / "timeout"), so callers can handle it explicitly.
  • Naming/shape (error type vs. event, exact name, fields) is still TBD — needs a decision as part of implementing this issue. @BigLep is happy to discuss/review.
• filecoin-pin CLI: on that specific mismatch, log an error; consider also collecting a metric/counter for it if the CLI has a metrics path.
• Update documentation/content-routing-faq.md (and any other docs referencing filecoinpin.contact or its negative-cache behavior) to reflect the new flow through Curio + cid.contact.
• Remove any remaining filecoinpin.contact references from code, config, and docs.

Notes

• This shouldn't be merged/released until Curio PDP SPs have all updated to a release that includes the Integrate IPNI /sync/status/ad/{adCid} to track confirmed advertisement indexing curio#1405 changes, so the new endpoint is actually available in the field.
• dealbot depends directly on this function. Changing its signature/behavior is a breaking change for dealbot, not just filecoin-pin's own CLI. See Stop polling filecoinpin.contact, use Curio piece-status endpoint instead FilOzone/dealbot#684
• filecoin-pin-website also depends on this function (src/hooks/use-ipni-check.ts calls waitForIpniProviderResults directly, with no explicit ipniIndexerUrl override), so bumping its filecoin-pin dependency should pick up the new behavior automatically. That version bump + the doc update to HTTP_REQUESTS_TO_CURIO.md (which currently describes GET https://filecoinpin.contact/cid/{cid}) is tracked as its own step in [Tracking] Migrate FOC off filecoinpin.contact, use cid.contact only #664.
• See [Tracking] Migrate FOC off filecoinpin.contact, use cid.contact only #664's "Intended solution" section for the full flow (Curio confirms indexing via cid.contact's /sync/status/ad/{adCid}, surfaces it on its own status endpoint, clients poll Curio rather than cid.contact directly, then do one confirming cid.contact query).

[BigLep]

@beck-8 @SgtPooki : I believe all the done criteria was met by #689. I'm closing but reopen if anything is missing.