project: add a release/packaging workflow (versioned builds + install path)

[mbertschler]

Problem

squirrel has no release or packaging story. There are no tagged releases, no prebuilt binaries, and no build-time version injection — the only documented way to get the tool is building from source at @latest:

go install github.com/mbertschler/squirrel/cmd/squirrel@latest

(README.md §Install)

Because nothing stamps a version at build time, the binary can't report what it is. The agent health version is a hardcoded placeholder:

// agentVersion is the value reported by GET /v1/health. A real release
// would inject this via -ldflags at build time; the placeholder is
// adequate for the unreleased peer-sync work.
const agentVersion = "0.0.0-dev"

(cmd/squirrel/agent.go:20)

So today: no squirrel version command, no meaningful version in GET /v1/health, no way to pin or roll back to a known build, and no artifact to install without a Go toolchain. There is a CI workflow (.github/workflows/ci.yml) but no release workflow.

Why it matters

• Reproducible deploys. Installing/pinning a specific version (and rolling back) is impossible when the only path is @latest from source.
• Version reporting. agentVersion / health should reflect the actual build, not 0.0.0-dev. Operators and peer-sync diagnostics benefit from an accurate version.
• rclone floor coupling. The tool already enforces a minimum rclone version (sync.EnsureMinVersion); a released squirrel build should be able to state its own version alongside that check.
• No toolchain install. A prebuilt binary lets the tool be installed where a Go toolchain isn't wanted.

Scope (decisions to make)

1. Versioning scheme — semver tags (vMAJOR.MINOR.PATCH) as the source of truth.
2. Build-time injection — inject version (and ideally commit + build date) via -ldflags -X, replacing the 0.0.0-dev placeholder; feed the same value to the agent health response.
3. squirrel version subcommand — print the injected version/commit/build info (own file, per the one-cobra-command-per-file convention).
4. Release automation — a tag-triggered GitHub Actions workflow that builds cross-platform binaries and publishes them as release assets (a tool like GoReleaser is the obvious fit; there's no .goreleaser config today).
5. Install docs — extend README.md §Install with the released-binary path alongside go install.

Out of scope

• Distro/Homebrew packaging — a later step once tagged releases and binaries exist.
• Any change to the migration/SchemaVersion machinery — the DB schema version is separate from the tool's release version and stays as-is.

Acceptance

• Pushing a vX.Y.Z tag produces a GitHub Release with cross-platform binaries.
• The released binary reports its version via a squirrel version command and via GET /v1/health (no more 0.0.0-dev), sourced from ldflags.
• README.md documents installing a released binary as well as go install.