Scoop manifest accumulates old app versions on update — add optional cleanup

Problem

Scoop's default behavior is to keep every previously-installed version of an
app in ~/scoop/apps/<app>/ after an update — it never removes old versions
automatically. This is intentional scoop behavior (it lets users roll back
with scoop reset app@version), but it means the entire scoop-bucket
install grows unbounded over time with zero action from the user.

On my own machine, old entire versions going back several releases were
sitting in the cli/ apps folder, totaling ~400MB of dead weight that
scoop cleanup would clear in one command — I just had no reason to know
to run it.

Desired behavior

$ scoop update entire/cli
Updating 'entire' (0.7.7 -> 0.7.8)
...
'entire' (0.7.8) was installed successfully!
Removing old versions: 0.7.6, 0.7.7

$ scoop info entire/cli

Name        : cli
Description : CLI for Entire
Version     : 0.7.8
Source      : entire
Website     : https://github.com/entireio/cli
License     : MIT
Updated at  : 30-Jun-26 9:14:08 PM
Updated by  : goreleaserbot
Installed   : 0.7.8  <-- only the current version remains installed
Binaries    : git-remote-entire.exe | entire.exe

Proposed solution

Add a post_install hook to the scoops: block in .goreleaser.yaml so
the generated scoop manifest runs scoop cleanup $app automatically after
every install/update. This is a config-only change — no Go code, no new
dependencies — and only affects the generated cli.json in
entireio/scoop-bucket.

Tradeoff to decide on

scoop cleanup removing old versions means users lose the ability to
scoop reset back to a previous version if an update breaks something.
That's the real design question here, not the mechanism. Three options,
roughly in order of how much rollback safety they preserve:

Option A — always cleanup (no guard)

post_install:
  - "Invoke-Expression \"scoop cleanup $app\""

Simplest. Runs on every install including the first one (harmless no-op
there — scoop just reports the app is already clean). Removes rollback
safety unconditionally, every time.

Option B — cleanup only when >1 version exists

post_install:
  - "if ((Get-ChildItem \"$dir\\..\" -Directory | Measure-Object).Count -gt 1) { Invoke-Expression \"scoop cleanup $app\" }"

Functionally near-identical to A (A is already a no-op on first install),
just avoids a cosmetic "already clean" print on fresh installs. Doesn't
change the rollback tradeoff at all — including this mainly to have it on
the table, but I don't think it's worth the extra complexity over A.

Option C — don't touch install/update behavior, just make cleanup discoverable
Leave scoop's default rollback-preserving behavior alone, and instead
surface scoop cleanup entire in release notes / docs / a entire doctor-style
hint, so users can clean up on their own terms when disk space matters to
them, without losing rollback by default.

My recommendation

I lean toward A — the disk usage is real and most users will never
manually run scoop cleanup, whereas anyone who does hit a broken release
and wants to roll back can still reinstall a specific version via GitHub
releases directly. But this is a product decision about what safety net to
give Windows users by default, so flagging both the tradeoff and my bias
explicitly rather than assuming.

Happy to open a PR once there's alignment on which option to go with.

Start in .goreleaser.yaml at the scoops configuration and inspect how it generates entireio/scoop-bucket/cli.json. First get maintainer agreement on whether to preserve rollback versions or add the proposed cleanup hook, then verify the generated manifest contains the accepted post-install behavior.