Fix pending-upload download race that purges local PVE files

[Leonorus]

Fixes Issue #14

Summary

Fix a data-loss race where /v1/download could delete a locally-created cache file before the watcher had uploaded it to S3.

PVE can write files such as cloud-init user-data ISOs directly into the proxs3 cache and immediately call activate_volume. During the watcher debounce window, S3 still returns HeadObject 404. Previously, handleDownload treated that as “deleted on S3”, purged the cached file, and lost the only copy.

Changes

• Add explicit durable PendingUpload metadata for locally authoritative files.
• Serve pending or metadata-less cached files locally and queue them for upload instead of purging or overwriting them from S3.
• Route download-triggered uploads through the watcher debounce path.
• Scan cache directories on watcher startup so unconfirmed local files survive daemon restarts.
• Skip age/size eviction for files still pending upload.
• Deduplicate background uploads, rerun uploads when a file changes mid-transfer, and cancel in-flight uploads on delete.
• Record S3 ETags after watcher uploads so cache staleness checks recognize freshly uploaded files.
• Add regression coverage for pending download handling, pending rewrite handling, startup scan, upload rerun/cancel behavior, and pending-upload eviction protection.
• Update debian/changelog.

Testing

• go test ./internal/cache passed.
• go test ./internal/api -run 'TestHandleDownload_LocalPendingUpload_ServedNotPurged|TestHandleDownload_PendingRewrite_ServesLocalNotS3|TestHandleDelete_CancelsInFlightUpload|TestUploadNewFile_RerunAfterTriggerDuringUpload|TestMarkPendingUpload|TestScanPendingUploads' passed.