[ENH] - decide brews to homebrew_casks migration path before any GoReleaser v3 upgrade

Feature description

Decide what to do about GoReleaser's brews deprecation before any v3 upgrade.

Current state:

• .goreleaser.yml publishes the frames formula to nebari-dev/homebrew-tap via the brews: section.
• brews is fully deprecated as of GoReleaser v2.16 and scheduled for removal in v3. The suggested replacement is homebrew_casks.
• release.yml pins goreleaser-action to version: "~> v2", so nothing breaks unattended; a v3 upgrade is a deliberate act.

The catch that makes this a decision rather than a rename: casks are a macOS-only install mechanism. The formula currently installs on Linux too (the v0.1.5 release was verified with brew install nebari-dev/tap/frames inside the homebrew/brew Linux container). Renaming brews to homebrew_casks would drop linuxbrew support for the CLI.

Options when v3 gets close:

1. Move to homebrew_casks and accept macOS-only brew installs; Linux users fall back to the release archives or go install.
2. Keep formula-based distribution by generating the formula outside GoReleaser (a small release step that renders the formula and pushes to the tap, replacing what brews does today).
3. Both: cask for macOS, self-managed formula for Linux.

No action needed until a GoReleaser v3 upgrade is on the table; the version pin is the guard.

Value and/or benefit

Prevents an unplanned loss of brew install on Linux (or a silently broken release pipeline) when someone eventually bumps GoReleaser past v2.

Anything else?

Context: nebari-frames#25 (CI rollout, where the pin was added) and the v0.1.5 release verification transcript showing the Linux brew install working.

Read .goreleaser.yml, release.yml, and the context from nebari-frames#25, then review the v0.1.5 Linux brew-install verification. Compare the three migration options and document a chosen path that preserves the intended macOS and Linux installation support before any GoReleaser v3 upgrade.