Investigate: Bitswap support in the provider for Bulletin interoperability

Note: This issue description is AI-generated and needs further triage
and thinking before acting on it. Treat it as a starting point for
discussion, not a finalized plan.

Summary

The provider currently supports HTTP-only data retrieval. This issue proposes
investigating Bitswap support in the provider, reusing the existing Bitswap
implementations from polkadot-sdk (sc-network) and litep2p as much as
possible, rather than writing a new one.

The goal is a shared, content-addressed retrieval plane between the provider
and the Bulletin Chain: a client asks for a CID and any peer holding the data
(Bulletin node or storage provider) can answer.

Motivation

• Easier migration from Bulletin (e.g. dotNS machinery). If the provider
  serves the same CIDs over the same Bitswap plane as Bulletin, data can be
  replicated and served from either side with no client-side changes and no
  flag day. Rollback is trivial while both sides serve.
• Coexistence. Bulletin as commitment/authorization tier + provider as
  durability/capacity tier, connected by a single retrieval plane. Bitswap is
  the read-only glue that makes storage location transparent to consumers.
• Ecosystem compatibility. Bulletin already serves data via Bitswap
  (IPFS/Kubo-compatible), so matching it keeps one client stack working across
  both.

Scope

1. Reuse assessment
   • polkadot-sdk (sc-network) Bitswap server: how coupled is it to the
     substrate client/block backend? Can the store interface be abstracted so
     the provider plugs in its own storage backend?
   • litep2p Bitswap support: server-side completeness, limits, and whether
     it can be embedded standalone in the provider.
   • Which of the two is the smaller lift, and can needed generalizations be
     upstreamed instead of forked?
2. Parity with Bulletin parameters
   • Block/message size limits, CID versions/codecs, chunking/DAG parameters
     must match Bulletin's so identical CIDs resolve identically on both sides.
3. Alternative approach: client-side switch instead of provider-side Bitswap
   • Instead of adding Bitswap to the provider, extend the TrustedApi/HOST
     layer to switch between retrieval transports (Bitswap for Bulletin, HTTP
     for the provider) behind one CID-based interface. Clients get the same
     "resolve CID from wherever it lives" property without any provider
     changes. Evaluate both directions and compare complexity, trust
     implications, and how well each supports gradual migration.

Non-goals

• Provider discovery mechanics (DHT vs chain-published hints) — assumption to
  be stated in the report, implementation tracked separately.

Deliverables

• Short report: reuse feasibility (polkadot-sdk vs litep2p), parameter
  parity with Bulletin, and recommendation between provider-side Bitswap vs
  the TrustedApi/HOST transport switch.
• If provider-side Bitswap looks feasible: small PoC serving a CID also stored
  on Bulletin, with one client retrieving the same CID from either source.

References

• Bulletin Chain TransactionStorage / Bitswap serving
• polkadot-sdk sc-network Bitswap implementation
• litep2p Bitswap protocol support