Investigation verdict:
- HTMX does NOT swap the FilePond container on the edit page; the
htmx:targetError in the crash log is unrelated noise
- The pre-destroy abort in destroyFilePondsIn has a wrong status check
(filters for nonexistent status 4, misses status 7 LOADING) but is
moot because no HTMX swap targets the FilePond container
- The load-file-error -> DID_THROW_ITEM_INVALID path is vulnerable
(passes t.status directly, unlike every other error handler which
wraps it), but for local files the LOAD_FILE plugins always wrap
rejections properly
- Likely actual trigger: Firefox XHR abort edge case in server.load
for the existing cover file, racing with addition of a new local file
that replaces it in the single-file queue
