fix(desktop): unlink destination before copying binaries

[vincenzopalazzo]

Summary

• prepare-platform-binaries.js used fs.copyFileSync/fs.cpSync directly onto existing destinations, truncating and rewriting executables in place. On macOS arm64 this invalidates the code signature of any running process mapped from that file, and the kernel SIGKILLs it (EXC_CRASH — Code Signature Invalid).
• Now unlinks the destination first (fresh inode), matching the Justfile copy-binary recipe. Running goose serve/goose acp processes survive a re-run of packaging.
• Documents the rule in AGENTS.md (## Never section).

Review Notes

• Production-safety review passed (2 rounds).
• Script is not covered by eslint (only src/**/*.ts); verified with node --check.
• Windows-only code paths changed (win32 branch + pinned uv binaries); macOS/Linux flows untouched.

Decision Log

Hardest decision: Whether to use copy-to-temp + atomic rename instead of unlink-then-copy. Chose unlink-then-copy to match the existing Justfile convention (rm -f + cp -p) — consistent, simpler, and the non-atomic window doesn't matter for a build script that owns its output directory.

Alternatives rejected:

• Atomic rename via temp file: marginally safer but introduces a second convention and more code for no practical gain here.
• Keep force: true on cpSync: redundant once the destination is removed first.

Least confident about: The file branch uses plain rmSync (not recursive), so it would throw if a directory ever existed at a file's destination path. That can't happen with the current fixed file set (goose-npm, *.cmd), and the old code failed identically in that scenario — so no regression, just not newly hardened.

Test plan

• CI passes
• Re-running desktop packaging while a packaged Goose.app is running no longer kills its goose serve process