Concept: web3-storage replica as a backing/durability tier for Bulletin

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

Summary

Instead of replacing Bulletin with web3-storage, explore coexistence:

• Bulletin stays the commitment/authorization tier — on-chain CID registry,
  authorization, payments, bounded retention window, data guaranteed by the
  chain for that window.
• web3-storage acts as a replica/durability tier — replicates data from
  Bulletin and keeps serving it past Bulletin's retention window, at larger
  capacity and with provider-based economics.
• Both connected via a shared retrieval plane (Bitswap and/or a client-side
  transport switch — see #390), so a CID resolves regardless of
  which tier currently holds the bytes.

Rough idea: Bulletin sells the guarantee, web3-storage sells the bytes.

Why

• Keeps Bulletin's on-chain commitment (queryable, light-client verifiable)
  without putting unbounded storage liability on Bulletin nodes.
• Gives long-lived products (e.g. dotNS) a durability story beyond Bulletin's
  retention window, without a disruptive migration.
• Could clarify "permanent" storage semantics: permanence fulfilled by the
  replica tier, only recorded/attested on Bulletin.

Non-goals (for now)

• Any implementation — this issue is for collecting thoughts and reaching a
  go/no-go on deeper design work.