release: migrate deprecated goreleaser `brews` key and pin GoReleaser version

[arimxyer]

Problem

Two coupled release-pipeline footguns surfaced while cutting v0.18.0:

1. .goreleaser.yml uses the deprecated brews: key. goreleaser check (v2.16.0) reports:

   DEPRECATED: brews should not be used anymore, check https://goreleaser.com/deprecations#brews
   .goreleaser.yml: configuration is valid, but uses deprecated properties
   

   It still publishes today because release/build only warn on deprecations (only check exits non-zero) — v0.18.0's Homebrew formula published fine. But when GoReleaser eventually removes brews, the publish step breaks.

2. Both .github/workflows/release.yml and ci.yml (Build job) pin GoReleaser version: latest. Combined with (1), a future GoReleaser release that drops brews would break the release with no advance warning — latest silently rolls forward at tag time.

Why it matters

The brew publish failure would happen after the v* tag is already created (the Release workflow isn't a required check), so a bad GoReleaser bump would leave a tag with a partially-failed release.

Options

• Migrate brews: → homebrew_casks: per https://goreleaser.com/deprecations#brews (note: formula → cask is a behavior change for a binary CLI; validate the install UX). Then goreleaser check is clean again.
• And/or pin a known-good GoReleaser version (version: 'v2.x.y') in both workflows instead of latest, so upgrades are deliberate and tested via the snapshot Build job before they can affect a real release.

Verification

goreleaser check should exit 0, and a goreleaser release --snapshot --clean dry-run should produce the cask/formula without deprecation errors.

Context: surfaced during the v0.18.0 / reyamira org-transfer release.

[arimxyer]

Interim fix in progress: pinning GoReleaser to v2.16.0 in both ci.yml and release.yml neutralizes the silent-rollforward risk (branch fix/release-pipeline-113-114). That keeps brews: publishing on a known-good version, so the deprecation is no longer urgent.

Two mutually-exclusive options for actually resolving the brews: deprecation captured as follow-ups (decide later):

• release: native per-platform distribution (Homebrew cask + nfpm deb/rpm/apk + Scoop) — Option A for #113 #117 — Option A: native per-platform distribution (Homebrew cask for macOS + nfpm .deb/.rpm/.apk for Linux + Scoop). Drops Linux brew; all inside GoReleaser.
• release: keep unified Homebrew formula, self-updated via CI — Option B for #113 #118 — Option B: keep a unified Homebrew formula (works on macOS + Linux), self-updated via a CI bump step, with GoReleaser no longer touching Homebrew. Smaller footprint; adds a second automation.

[arimxyer]

Decision (2026-07-01).

• ✅ Pinning done. GoReleaser is pinned to v2.16.0 in both release.yml and ci.yml (ci: harden release pipeline (#113, #114) #119). v2.16.0 still ships brews: (deprecation warning only), so publishing to mac (universal) + Linux works today; nothing breaks until the pin is deliberately bumped past the brews: removal.
• ❌ Not migrating brews: → homebrew_casks:. Casks are macOS-only and would drop Linux brew users. Closed release: native per-platform distribution (Homebrew cask + nfpm deb/rpm/apk + Scoop) — Option A for #113 #117.
• 🎯 Target: homebrew-core, once pass-cli meets Homebrew's notability/acceptable-formulae bar (not yet). That yields a real formula with central bottles for mac + Linux and brew install pass-cli (no tap prefix) — the same channel as reyamira/models. This makes the A/B question moot.
• 🩹 Interim, only if we unpin GoReleaser before then: keep a unified formula generated by a small CI step instead of the deprecated brews: key — tracked in release: keep unified Homebrew formula, self-updated via CI — Option B for #113 #118 (low priority while pinned).

Keeping this umbrella open to track the homebrew-core submission.