fix(release): emit postflight_steps in the Homebrew cask

[leinardi]

Summary

Installing the cask from the tap printed a deprecation warning on every brew command that touched it:

Warning: Calling `postflight` is deprecated! Use `postflight_steps` instead.
Please report this issue to the leinardi/homebrew-tap tap (not Homebrew/* repositories), or even better, submit a PR to fix it:
  /opt/homebrew/Library/Taps/leinardi/homebrew-tap/Casks/monmux.rb:25

Cause

goreleaser renders homebrew_casks.hooks.post.install as a Ruby postflight do … end block. Homebrew has replaced flight blocks with the declarative *_steps stanzas. Official taps already reject the old blocks (Homebrew/brew#23366); third-party taps get this warning until a later removal. Once that removal lands, the quarantine strip would silently stop running and Gatekeeper would refuse the unsigned binary. The tap file is generated, so the fix has to be in .goreleaser.yaml.

Fix

goreleaser v2.18.1 has no option that emits the new stanza. goreleaser/goreleaser#6873 adds hooks.post.install_steps, but it is still open. Until it ships, the block goes through custom_block:

postflight_steps do
  on_macos do
    run "/usr/bin/xattr",
        args:         ["-dr", "com.apple.quarantine", "{{staged_path}}/monmux"],
        must_succeed: false
  end
end

• goreleaser templates the whole cask, so the YAML escapes Homebrew's {{staged_path}} token.
• must_succeed: false is deliberate. The old system_command never raised either, and xattr -d exits 1 when the attribute is absent, which would fail the install for no reason. stderr stays visible, so a real failure still shows.
• custom_block puts the stanza before the artifact stanzas. brew style flags that order; installing ignores it, and the tap runs no style check. Moving to install_steps once goreleaser releases it fixes the order. The YAML comment says so.

Docs

• docs/release.md and docs/security.md name the new stanza.
• docs/security.md no longer compares the strip to brew install --cask --no-quarantine, because Homebrew removed that flag.
• README.md adds one sentence on why monmux info masks Handle: on macOS but not on Linux. The macOS handle is the display UUID, redacted like a serial; the Linux handle is only the connector name. That difference is intended, and now written down.

Testing

• goreleaser release --snapshot --clean --skip=publish,sign with the pinned v2.18.1: the generated dist/homebrew/Casks/monmux.rb contains the block above with a literal {{staged_path}}, and no postflight do or preflight do.
• By hand on an Apple Silicon Mac, against the v0.6.0 release archive, with the tap's cask temporarily replaced:
  • Control, a cask with no strip: the binary keeps com.apple.quarantine, and running it brings up Gatekeeper's "Apple could not verify" dialog.
  • The rendered block: install and reinstall print no deprecation warning, xattr -l shows no quarantine attribute, and monmux version (exit 0) and monmux info run.
• make check passes.

Pull request checklist

• I am targeting the main branch
• I have rebased this branch on top of the destination branch
• I have executed make check locally before creating the commit and it has run successfully
• I have performed a self-review of my own code
• There are no WIP commits in this PR

Monitor writes

None. internal/catalog/models.yaml is not in the diff, and no code changed. The only monmux commands run on hardware were version and info, both read-only, run by hand on the Mac.

• If this changes internal/catalog/models.yaml, the evidence is in the entry, and the Summary above says which model
  and which input it enables — not applicable
• No hardware run in this pull request was performed by an AI agent — AGENTS.md

Type of changes

• 🐛 Bug fix
• ✨ New feature
• 🖥️ Catalog (a model or an input recorded, enabled or corrected)
• 🔧 Refactoring
• 📜 Docs
• 🧰 CI / tooling / infra
• Other (describe in Summary)