ci(packaging): lint the Homebrew cask on pull requests

[jpicklyk]

Summary

brew style / brew audit only ran in publish-packages.yml's homebrew job, after a release is published, so a template change that broke one of Homebrew's rules merged cleanly and first failed in the publish run. That is how the Homebrew/OSDependsOn offense from #49's fix blocked the 0.13.3 republish (fixed in #50).

• .github/workflows/verify-homebrew.yml (new) runs on macos-latest for PRs that touch packaging/homebrew/**, scripts/render-packaging.mjs, the lint action or the workflow itself, and on workflow_dispatch (optional version, default latest release). It resolves the latest release the way verify-chocolatey.yml does, renders the cask, and runs the lint. It pushes nothing and uses no PAT or tap checkout.
• .github/actions/homebrew-lint (new composite action) holds the shared steps: brew update, copy the rendered cask into a directory and symlink that directory in as the jpicklyk/logtapper tap, brew style --cask, then brew audit --cask --online with HOMEBREW_GITHUB_API_TOKEN. The publish job now calls it too, so the PR check and the release gate cannot drift.
• packaging/README.md describes the lint, the PR check and what it does not cover.

Things worth checking

• The DMG hashes are real, not dummies. --online implies a download in cask/audit.rb (download ||= online || signing), and Download#fetch verifies the checksum. So verify-chocolatey.yml's dummy-DMG-hash trick would fail the audit here. Only the NSIS hash, which the cask does not use, is a dummy. That skips one download and keeps the linted cask byte-identical to what publish would push for that version.
• brew update now runs before the tap is registered (before this PR it ran after). This keeps it from fetching into the publish job's tap checkout. The lint result is unchanged.
• It runs only when those paths change. A new rule on Homebrew's side, like the Big Sur minimum that disabled :catalina, still fails an unchanged template in the next publish run first. Dispatching the workflow checks the latest release against current Homebrew. A weekly schedule trigger would close that gap if wanted.

Test plan

• The render command from the workflow, run locally against v0.13.3: both DMGs hashed, installer download skipped, cask rendered
• All three YAML files parse (js-yaml)
• Verify Homebrew cask passes on this PR, which touches the workflow and the action. This is the first time the composite action runs, and the first time the tap is a plain directory rather than a git checkout.
• The publish job's use of the action is exercised on the next release or dispatch. It is the same action with tap-dir: tap pointing at the homebrew-logtapper checkout.

🤖 Generated with Claude Code