fix(download): surface allocating state on reconnect + reset per-file progress on data-only delete

[lukyrys]

Summary

Two related download-state fixes.

1. Allocating state survives a reconnect

A download in the file-allocation (zero-fill) phase has no peers yet, so after a WebSocket reconnect the active-transfers snapshot reported it as a plain downloading transfer with 0 peers — which the UI then computed as idle. It now reports the allocation phase distinctly.

• Downloader.isAllocating() exposes the preparing state.
• getActiveTransfers() emits type: 'allocating' for downloaders still allocating.
• On reconnect the frontend maps an allocating transfer straight to the allocating status instead of falling back to idle.

2. Per-file progress reset after a data-only delete

After deleting only the data of a LISH (keeping the manifest), the per-file progress bars stayed at their previous values. The detail view now resets per-file verify/progress state so they correctly show 0%.

Verification

• bun run typecheck (backend) — pass
• bun run check (frontend) — 0 errors / 0 warnings
• Allocating-across-reconnect verified end-to-end with a real two-node download (seeder + downloader): during allocation the snapshot reports allocating with 0 peers, and a page reload mid-allocation shows the allocating status rather than idle.
• Data-only delete verified in the UI: file progress goes 100% → 0%.