cherry upgrade: new binary fails with 'error: AccessDenied' while the old version is still running

Seen upgrading 0.3.0 → 0.4.0 on Windows with a `cherry serve` still running from the old binary. The upgrade itself succeeds (self-swap works, old exe parked as `.old`), but every invocation of the new binary exits 1 with just `error: AccessDenied` until the old process stops — Burrito's wrapper attempts to uninstall the previous version's payload dir on first run, and the running instance holds it locked. Once the old process exited, the next run printed `[l] Uninstalled older version (v0.3.0)` and worked. Options: tolerate cleanup failure and retry next run, or message it clearly. Cleanup lives in Burrito's zig wrapper, so may need an upstream issue.

Start with Burrito's Zig wrapper cleanup path and reproduce the 0.3.0 to 0.4.0 upgrade on Windows while an old `cherry serve` process is running. Verify that the new binary no longer exits with `AccessDenied`, either by deferring cleanup for a later run or clearly reporting the locked payload state.

Written by the indexing model from the issue text.