demm Strolled through the changelogs of all recent versions (mainline, beta, nightly, esr) and noticed this in Firefox 126 for developers -
HTTP
The zstd directive of the Content-Encoding HTTP header is now supported, allowing decoding of server-sent content encoded with the Zstandard compression algorithm (Firefox bug 1871963).
Which in turn led to a bunch of regressions regarding the implementation of zstd; stuff that was labelled as broken for version 126 but was fixed in 127. It seems that removal of a certain compilation flag fixes it.
Seems to attest that this fiasco of firefox was indeed about zstd. As mentioned here -
brotli achieves compression density by more computation whereas zstd is relying on more memory access (larger window size). Even in the area of normal operation ... zstd, the server has no way to actually know if the client will be able to decode the stream if the request is for more than 8 MB ... zstd defaults to larger window sizes (often 128 MB vs. brotli's 4 MB). When used in a browser environment, usual deployments use smaller window size because larger window sizes mean more OutofMemory errors in browsers.
And the error logs mentioned in this thread by us, too, categorically point towards Signal 11 (SIGSEGV, segmentation violation) that is the browser tried to accessed a memory location that was not assigned to it.