#3621 swamp update on Windows leaves no complete swamp.exe during a cross-volume copy, and keeps the zip until it finishes

Problem

Found while working on swamp-club#3618 (install.ps1 replaces swamp.exe unsafely). swamp update on Windows already renames the running binary aside to swamp.exe.old, and rolls back if the new binary can't be placed. Two gaps remain, both in src/infrastructure/update/http_update_checker.ts.

1. The destination has no complete swamp.exe while the new binary is copied in across volumes. replaceBinaryWindows renames swamp.exe to swamp.exe.old before placing the new binary. When the temp dir is on a different volume from the install (for example %TEMP% on D: and swamp on C:), the rename fails with EXDEV and it falls back to Deno.copyFile(sourcePath, targetPath), writing straight to swamp.exe. For the whole copy, swamp.exe is missing or partial. If the process is killed mid-copy (Ctrl+C is blocked by then, but a crash, a kill or a power loss is not), there is no rollback: the user is left with a truncated swamp.exe and the working binary sitting at swamp.exe.old.
2. The downloaded zip stays on disk until the temp dir is removed. downloadAndInstall keeps swamp.zip in its temp dir through extraction and the replace, and only removes it in finally. So the zip, the extracted binary and the old binary are all on disk at once. swamp-club#3515 fixed the same thing for install.sh, and #3618 fixes it for install.ps1.

Expected

1. Copy the new binary to a temp file in the destination directory first (the .swamp.tmp. prefix that removeAbandonedTempFiles already sweeps), then rename the old binary aside and rename the temp file into place. Both renames stay within one directory, so swamp.exe is only absent between two renames, and a failure at any point leaves a working binary at swamp.exe or swamp.exe.old. The POSIX EXDEV path already does this.
2. Delete the archive once it has been verified and extracted, before the replace.

Output, flags and exit codes stay the same.