[fohara]

Adds brew install fixture-dev/tap/lash for macOS and Linux.

What this does

Turns on cargo-dist's Homebrew installer rather than hand-maintaining a formula.
The generated lash.rb points at the prebuilt release tarballs for both macOS
arches and both Linux arches, so brew install downloads a binary instead of
compiling, and Linuxbrew works for free. A publish-homebrew-formula job commits
the formula to fixture-dev/homebrew-tap
on each release; nothing needs doing per release.

Changes

• dist-workspace.toml: homebrew added to installers, plus tap and publish-jobs
• .github/workflows/release.yml: regenerated with dist generate
• Cargo.toml / lash-cli: added homepage (the Homebrew installer warns without it),
  and replaced the self-referential crate description, which becomes the formula's
  desc and shows up in brew info
• README.md: install section, plus a note that mixing install methods puts two
  lash binaries on PATH (~/.cargo/bin vs the brew prefix)
• CONTRIBUTING.md: tap setup, token-expiry troubleshooting, and the hand-patch below

One hand-patch in the generated workflow

dist 0.28.5+ emits persist-credentials: false on the tap checkout, but the job
ends in a bare git push that needs those credentials, so it fails with
could not read Username for 'https://github.com/'. That's
astral-sh/cargo-dist#29,
still unfixed upstream. One line is flipped to true, marked LOCAL PATCH in the
file and documented in CONTRIBUTING — dist generate silently reverts it.

Considered pinning dist back to 0.28.3 and owning the publish job via a custom
workflow; the patch won because losing it fails the job loudly rather than
shipping a stale formula.

Verification

• Formula generated locally with dist build --artifacts=global, valid Ruby per
  ruby -c, correct URLs for all four Unix targets
• release.yml parses; only the Homebrew checkout's persist-credentials changed
• Tap repo exists and is public, seeded with a README (actions/checkout cannot
  check out a repo with no commits), and HOMEBREW_TAP_TOKEN is registered

The publish job itself can only be proven by a real tagged release. If it fails it
does so after the GitHub Release is created, which is recoverable by fixing and
re-running the job without re-tagging.