fix(files): throw on empty REST body to avoid TypeError after self-replace

[epeicher]

Summary

When desktop-mode replaces itself live (Plugins window → Upload .zip → Replace), REST routes briefly re-register and a 2xx response can land with an empty or unparseable body. The files REST client previously returned null as T, which crashed the folder-hydration consumer in src/desktop-files/layer.ts with:

[desktop-mode] files: failed to hydrate folder 0 TypeError: Cannot read properties of null (reading 'placements')

Fix at the boundary: in src/desktop-files/rest.ts's call(), throw when the body is null on a 2xx. Every consumer in the files module expects a shaped object, so a null body is never legitimate. The existing .catch handlers now log a single meaningful line:

[desktop-mode] files: failed to hydrate folder 0 Error: [desktop-mode] files REST 200: empty or unparseable body.

Boundary fix > per-consumer guard: one change covers listPlacements, listFolders, restoreTrashedItem, etc., and produces a clearer signal than silently no-op'ing.

The 409 (Conflict) console line that also appears in the issue is expected — it's the server's "this plugin folder already exists, replace?" signal that upload-dialog.ts handles correctly. Out of scope for this PR.

Refs #212.

Test plan

• On a site with desktop-mode active, open the Plugins window and upload the desktop-mode .zip.
• Confirm the "Replace existing plugin?" dialog appears (409 path still works).
• Click Replace; upload completes.
• CTRL+R the page; the TypeError on folder hydration no longer fires.
• If the transient empty-body race still hits, the console shows the new clear message instead of the TypeError, and the desktop layer keeps working.
• npm run lint, tsc --noEmit, npm run test:js all pass.

[github-actions]

✅ WordPress Plugin Check Report

✅ Status: Passed

📊 Report

All checks passed! No errors or warnings found.

---

🤖 Generated by WordPress Plugin Check Action • Learn more about Plugin Check