fix(lib): fix error message and name the codec when a dataset cannot be decoded

[eeholmes]

A dataset whose chunks use a codec gridlook has no decoder for fails in a way that is indistinguishable from a slow or unreachable host: the store opens, every variable is listed, and only the first chunk read fails — and gives the user a "Could not fetch data" error but that is not the problem and it interferes with debugging. zarrita names the codec precisely, but nothing carried the name through to the user.

This PR makes the error surface into the message that appears for the user. I tried to make minimal changes to the upstream code. Just enough to surface the error.

Note, I don't have a url to demo the error message. I will post a comment once I do.

With this change to src/lib/data/codecErrors.ts, it now recognises three cases and rewrites each into a message naming the culprit:

• an unregistered codec -> "Unsupported codec: numcodecs.quantize"
• a codec that rejected a chunk -> the codec, plus the reason it threw
• a data type the browser lacks -> the type, plus the browsers that have it

Behaviour is unchanged and no decoder is added: an unsupported dataset still fails, it just says why — and says it precisely enough to report.

Errors are matched both structurally and by message text, because the grid data worker flattens them to a plain string before posting back, which loses the error class and its fields. That flattening also dropped the reason a codec threw, which zarrita puts on cause, so gridData.worker.ts now appends it.

[Karinon]

Thanks for the PR and I think the idea is neat. I tried it by commenting out our custom logBins-codec and loading one Zarr File from Chalmers Ice Climatology ( https://chalmerscloudiceclimatology.s3.amazonaws.com/record/cpcir/2000/ccic_cpcir_200005100200.zarr ).

The formatting is a bit hard to read, but this is an issue with our Toast component and should be tackled separately.

Other than that I have only a few nitpicks.

[Karinon]

I would be really interested in seeing such a file. I haven't seen datatype issues like this in a long time, but I haven't checked older browsers.

[eeholmes]

See comment. Below. Happy to drop if you prefer. It is just an issue for older browsers.

[eeholmes]

@Karinon

Thanks for the review — and for going to the trouble of reproducing it by commenting out logBins.

Both naming points are done in be2dfb0:

• explainDataError → explainCodecError, and the type followed it to TCodecErrorExplanation.
• flattenErrorMessage moved to src/utils/errorHandling.ts, next to getErrorMessage and toNormalizedError, with its unit tests alongside it in tests/unit/utils/errorHandling.test.ts.

On the float16 branch — that it isn't a live problem. zarrita maps float16 onto globalThis.Float16Array, which landed in Chrome 135, Firefox 129 and Safari 26. Any current browser it works fine. It's also a different failure from the codec cases: without Float16Array the array can't be opened at all. Honestly it went in because Claude was being extra thorough when I requested clearer error so I can debug easier, not because I ran into it. So I don't have a file to show you.

So I'm happy to drop it. That would also settle your first point: with the dtype case gone the file explains nothing but codec errors, and explainCodecError becomes exactly accurate rather than approximately. Let me know and I'll push a fix with that dtype case removed; or I can leave it as a guard for anyone on an older browser (older than 1-2 years).