bug: `FetchErrorPage` crashes when IPNS name is a DNSLink (not a CID)

[lidel]

Reproduction

1. Open https://share-ipfs-io.ipns.inbrowser.link
2. Trigger any fetch error (or wait for one to occur)
3. Error page crashes instead of rendering

{
  "name": "Error",
  "message": "To parse non base32, base36 or base58btc encoded CID multibase decoder must be provided",
  "stack": "Error: To parse non base32, base36 or base58btc encoded CID multibase decoder must be provided\n    at parseCIDtoBytes (https://share-ipfs-io.ipns.inbrowser.link/ipfs-sw-index-DXCWGXZY.js:17747:15)\n    at _CID.parse (https://share-ipfs-io.ipns.inbrowser.link/ipfs-sw-index-DXCWGXZY.js:17714:29)\n    at createLink (https://share-ipfs-io.ipns.inbrowser.link/ipfs-sw-index-DXCWGXZY.js:24326:36)\n    at FetchErrorPage (https://share-ipfs-io.ipns.inbrowser.link/ipfs-sw-index-DXCWGXZY.js:24449:1477)\n    at renderWithHooks (https://share-ipfs-io.ipns.inbrowser.link/ipfs-sw-index-DXCWGXZY.js:4173:25)\n    at updateFunctionComponent (https://share-ipfs-io.ipns.inbrowser.link/ipfs-sw-index-DXCWGXZY.js:5804:20)\n    at beginWork (https://share-ipfs-io.ipns.inbrowser.link/ipfs-sw-index-DXCWGXZY.js:6415:18)\n    at performUnitOfWork (https://share-ipfs-io.ipns.inbrowser.link/ipfs-sw-index-DXCWGXZY.js:9220:18)\n    at workLoopSync (https://share-ipfs-io.ipns.inbrowser.link/ipfs-sw-index-DXCWGXZY.js:9118:41)\n    at renderRootSync (https://share-ipfs-io.ipns.inbrowser.link/ipfs-sw-index-DXCWGXZY.js:9102:11)"
}

Root cause

I guess createLink() calls CID.parse() assuming all IPNS names are CIDs, but DNSLink names like share-ipfs-io are not valid CIDs.

Expected behavior

createLink() should check if the IPNS name is a valid CID before calling CID.parse(), and handle DNS names gracefully somehow.

cc @achingbrain mind taking a look? i dont have strong preference here, whatever you feel is the good way of handling this to give user meaningful error page (did dnslink fail? did we get CID but could not retrieve it?)

[achingbrain]

Fixed by ipfs/helia-verified-fetch#307 - will be available in the next inbrowser.link deployment.

[achingbrain]

The website 504s on https://share-ipfs-io.ipns.inbrowser.dev now, rather than 500ing.