#3618 install.ps1 keeps the release zip until exit and deletes the old swamp.exe before copying the new one

Problem

Follow-up to swamp-club#3515 (swamp PR https://github.com/swamp-club/swamp/pull/3194, 44343a9e), which made install.sh delete the release archive as soon as the binary is extracted. scripts/install.ps1 has the same pattern and one more problem.

1. The archive stays on disk until the end. install.ps1 downloads swamp.zip into a temp dir, extracts it into extract, then copies the binary into place (Install-Binary, Copy-Item, around line 318). The temp dir is only removed in the final finally (around line 499). So a fresh install peaks at the zip, plus the extracted binary, plus the installed copy.
2. The old binary is deleted before the new one is copied. Install-Binary runs Remove-Item $destFile -Force and then Copy-Item (around lines 315–318).
   • If the copy fails (disk full, AV quarantine, a permissions error), the user has no swamp at all.
   • If swamp.exe is running, Windows locks it, so the delete fails and an upgrade over a running swamp can't complete.

Expected

1. As in #3515: delete swamp.zip and its .sha256 once they've been verified and extracted. Output, flags and exit codes stay the same.
2. Never leave the destination without a working swamp.exe. Copy or move the new binary next to the old one, then replace it. When the old binary is locked, rename it aside (Windows allows renaming a running exe) and clean it up on the next install or update. Report a clear error if the replace can't complete, rather than leaving no binary.
3. Check whether swamp update on Windows replaces the binary the same way. Report only.

Notes

#3515 rejected moving the binary into place for install.sh because of root-run installs writing into the destination directory. Windows installs are per-user by default, so check whether that reasoning applies here.

Related: swamp-club#3596 (corporate Windows only allows running programs from approved folders).