feat: package gro and grw from one release stream

[rianjs]

Summary

• .goreleaser.yaml: four builds (gro-darwin, gro-unix-win, grw-darwin, grw-unix-win), per-binary archives (gro_v…, grw_v…), nfpm packages (google-readonly, google-readwrite), and skip_upload casks (gro, grw) pointed at the tap.
• packaging/identity.yml (open-cli-identity/v1, binaries: list): gro keeps its google-readonly identifiers on Chocolatey, WinGet, Linux, and the tap alias; grw ships as grw with a WinGet bootstrap and a google-readwrite tap alias. Keychain probes for both identities.
• Nested Chocolatey packages under packaging/chocolatey/<id>/ and six WinGet manifests.
• Thin auto-release.yml and release.yml callers of the shared @v1 workflows; version.txt starts the 1.2 stream.
• CI gains an identity-check job.

Depends on open-cli-collective/.github#42 (the shared validator wrongly attributed cask ids through the build map); identity-check goes green once that lands on v1.

Closes #5

Test plan

• goreleaser check and goreleaser release --snapshot --clean --skip=publish pass locally: twelve archives, one Windows/amd64 archive per binary owned by archive ids gro/grw
• identity.py validate passes against the real config with the #42 fix
• actionlint passes; make check passes

[monit-reviewer]

Automated PR Review

Reviewed commit: 5058e42

Approved with 2 non-blocking suggestions below. Address at your discretion.

Summary

Reviewer	Findings
harness-engineering:harness-knowledge-reviewer	2

harness-engineering:harness-knowledge-reviewer (2 findings)

💡 Suggestion - packaging/identity.yml:1

This PR introduces a new open-cli-identity/v1 schema (canonical vs. alias casks, per-binary keychain_probe assertions, custom version_scheme) and pairs it with a new goreleaser architecture (one release stream producing per-binary builds/archives/nfpm packages for gro and grw). None of this design rationale is captured as prose in the repo — only inferable from the YAML and the PR description, which will scroll out of view. A short packaging doc (e.g. docs/packaging.md) explaining the schema's purpose, the naming/aliasing convention (why gro keeps 'google-readonly' while grw is canonical with a 'google-readwrite' alias), what keychain_probe protects, and why one release stream was chosen over two would help future maintainers extend this safely.

💡 Suggestion - version.txt:1

version.txt starts the '1.2' stream using the version_scheme 'major_minor_run_patch' declared in packaging/identity.yml, but neither file nor any doc explains what this scheme means or why the stream starts at 1.2 rather than 1.0. A one-line note in a packaging doc (or a comment near the tag: block) would prevent this from becoming tribal knowledge.

---

Completed in 1m 27s | $1.31 | sonnet | daemon 0.2.142 | Glorfindel

Field	Value
Model	sonnet
Reviewers	hybrid-synthesis, harness-engineering:harness-architecture-reviewer, harness-engineering:harness-enforcement-reviewer, harness-engineering:harness-knowledge-reviewer
Engine	claude · sonnet
Reviewed by	pr-review-daemon · monit-pr-reviewer
Duration	1m 27s wall · 1m 22s compute (Reviewers: 55s · Synthesis: 28s)
Cost	$1.31 (estimated)
Tokens	292.8k in / 10.3k out
Turns	8

Per-workstream usage

Workstream	Model	In	Out	Cache read	Cache create	Cost
hybrid-synthesis	sonnet	59.4k	2.3k	26.4k	33.0k (1h)	$0.24
harness-engineering:harness-architecture-reviewer	sonnet	75.4k	597	26.4k	48.9k (1h)	$0.31
harness-engineering:harness-enforcement-reviewer	sonnet	79.7k	4.3k	26.4k	53.3k (1h)	$0.39
harness-engineering:harness-knowledge-reviewer	sonnet	78.3k	3.1k	26.4k	51.9k (1h)	$0.37

_{Re-reviews only run when @monit-reviewer is re-requested as a reviewer — push as many commits as you need, then re-request when ready. PRs targeting branches other than main, master are skipped, even when @monit-reviewer is re-requested.}

[monit-reviewer]

🔵 Low (harness-engineering:harness-knowledge-reviewer): This PR introduces a new open-cli-identity/v1 schema (canonical vs. alias casks, per-binary keychain_probe assertions, custom version_scheme) and pairs it with a new goreleaser architecture (one release stream producing per-binary builds/archives/nfpm packages for gro and grw). None of this design rationale is captured as prose in the repo — only inferable from the YAML and the PR description, which will scroll out of view. A short packaging doc (e.g. docs/packaging.md) explaining the schema's purpose, the naming/aliasing convention (why gro keeps 'google-readonly' while grw is canonical with a 'google-readwrite' alias), what keychain_probe protects, and why one release stream was chosen over two would help future maintainers extend this safely.

Reply to this thread when addressed.

[rianjs]

Addressed: added a 'Packaging identity' section to docs/development.md covering the schema (linking the cli-common distribution standard rather than restating it), the naming/alias rule and why gro keeps google-readonly, and what keychain_probe protects.

[monit-reviewer]

🔵 Low (harness-engineering:harness-knowledge-reviewer): version.txt starts the '1.2' stream using the version_scheme 'major_minor_run_patch' declared in packaging/identity.yml, but neither file nor any doc explains what this scheme means or why the stream starts at 1.2 rather than 1.0. A one-line note in a packaging doc (or a comment near the tag: block) would prevent this from becoming tribal knowledge.

Reply to this thread when addressed.

[rianjs]

Addressed: the same section explains major_minor_run_patch (tags are v1.2.N with the run number) and why the stream starts at 1.2 (gro already shipped 1.1.x).