ci: update IPFS and DNSLink deployment

[aschmahmann]

Updates the IPFS + DNSLink deployment.

Some questions for review:

1. How do we want to handle preview / PR websites (both when submitted within the repo and from a fork)?
2. Are we happy with the GH environment separations here, should there be more / less of them?

cc @achingbrain @lidel

[lidel]

Thank you for pushing this forward, quick feedback (can sync on Wednesday when i'm back):

• previews are provided by ipfs/ipfs-deploy-action -- it will create comment like this one
  • in theory, we could limit how long our cluster keeps PR previews by setting cluster-pin-expire-in on PR builds, but websites like helia.io are tiny so ok to pin forewer and figure out expiration in follow-up PR
• ⚠️ this needs to be refactored to avoid security issues, see two workflow model in: https://github.com/ipshipyard/ipfs-deploy-action?tab=readme-ov-file#dual-workflows-with-fork-prs
  • DNSLink update (if we are using Cloudflare token secret in CI) must be updated in Deploy workflow, and not the build one which could have thrid-party code
  • TLDR: Build works without secrets, Deploy uses code from master, and not fork, and uses output from Build. If we follow this, the surface for abuse via fork PR is removed.

[lidel]

lgtm, I guess we merge and see how it behaves in main, and if any issues, fix in follow-up commit/pr

[lidel]

https://github.com/ipshipyard/www-helia-io/actions/runs/19945830027/job/57194943496#step:2:59 looks fine, updated DNSLink to the new CID:

$ dig +short TXT _dnslink.helia.io.helia-io.dnslinks.ipshipyard.tech
"dnslink=/ipfs/bafybeiabia2lst6d26zajdqsausqdsj3opcggxtazlatwgnmw6wlvcf7u4"

I'll update CNAME to use ipshipyard.tech instead of Fleek.