docs: HTMX/destroy race hypothesis investigation — REFUTED

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

TODO.md

@@ -18,5 +18,6 @@ Reference: `docs/autosave-system.md` → "HTMX v2 Migration Plan" section.
 
 - [x] Analyze root cause → `docs/filepond-crash-analysis.md`
 - [x] Partial fixes (Content-Type headers, onerror cleanup, load object) — insufficient, crash still reproduces
-- [ ] Replace `server.load` with custom function to bypass FilePond's buggy `load-file-error` → `DID_THROW_ITEM_INVALID` dispatch (see analysis doc, Option B)
-- [ ] Implement `destroyFilePondsIn()` pre-destroy abort (defense in depth)
+- [x] HTMX/destroy race hypothesis investigation → `docs/filepond-race-investigation.md` (verdict: REFUTED; likely cause: Firefox XHR abort edge in server.load racing with file replacement)
+- [ ] Replace `server.load` with custom fetch-based function to bypass FilePond's `createResponse` path entirely (see investigation doc, recommended next step)
+- [ ] Fix `destroyFilePondsIn()` status check: `f.status === 7` (LOADING) not caught; needs to also cover LOADING and PROCESSING_QUEUED (status 9)