feat(go): tag-based release workflow, making the Go SDK an installable versioned package

[albertovincenzi]

Right now the Go module has never been tagged. channel-go (and anyone else) can only pin it via go get .../go@main, which resolves to a pseudo-version — a 40-char commit hash dressed up as v0.0.0-20260729191540-5d924496dffb. That's what prompted this: it should be a normal go get .../go@v1.2.3 package.

Why go/vX.Y.Z and not vX.Y.Z

This is a multi-module repo (go/, js/, php/, java/). Go's own spec for a module living in a subdirectory requires the tag to be prefixed with that subdirectory (go.dev/ref/mod#vcs-version) — plain vX.Y.Z tags (which this repo already has, e.g. v2.7.2) are not visible to the Go module resolver for go/ at all. Verified locally with a throwaway module + a filesystem Go proxy: a go/v1.0.0 tag resolves via go get module@v1.0.0, a bare v1.0.0 tag on the same commit does not.

Also worth knowing before picking a first version: those existing root vX.Y.Z tags don't track anything reliably — I diffed each one against what js/package.json said at that commit and they don't match (e.g. tag v2.7.2 → package.json 2.4.0, non-monotonically). So there's no existing "shared version line" to continue; Go starting its own independent count is not a regression, it's the status quo made explicit for a fourth package.

Why only v0/v1

The module path is github.com/smartpricing/traceflow-sdk/go — no /v2 suffix. Per Semantic Import Versioning, Go refuses to resolve any v2+ tag against a path that doesn't end in /v2. Reproduced this too: tagging go/v2.0.0 and requesting it gives invalid version: should be v0 or v1, not v2. So this is enforced both in the workflow (rejects a version input with major ≥ 2) and documented in go/README.md#versioning, so nobody tags a v2 by hand and ships something no consumer can go get.

What's in this PR

• go-release.yml — workflow_dispatch, input version (e.g. 1.0.0). Runs go vet + go test -race first, refuses to re-tag an existing version, tags go/vX.Y.Z, cuts a GitHub Release with notes scoped since the previous go/ tag (first release has none to scope against, handled). There's no build/publish step beyond the tag — that's how Go modules work, proxy.golang.org fetches directly from the tag on first request.
• go-ci.yml — go vet + go test -race on every push/PR touching go/**. There was no CI at all running the Go suite outside of this new release gate — a regression in go/ could land on main unnoticed until someone happened to run the tests locally (which is exactly how the recent sanitize()/omitempty bug went unnoticed for as long as it did).
• go/README.md — new Versioning section covering the above so it's not just in a PR description.

Rollout, once merged

Dispatch the workflow with version: 1.0.0 for the current main (5d92449, which already has the omitempty fix). That gives every consumer, starting with channel-go, a real tag to pin instead of a commit hash. Not doing that dispatch as part of this PR on purpose — cutting the first tag is a one-way door for anyone who fetches it, so leaving that as an explicit separate action.