ci: the race detector never runs, though make test declares it

[euxaristia]

Summary

The Makefile declares race testing as the project's test command, but no
workflow ever runs it. make test is:

test:
	go test ./... -race -count=1

CI does not invoke that target. ci.yml:79 and pr-auto-review.yml:42 both run
plain go test ./..., and -race appears nowhere else under
.github/workflows/. So the race detector has never run on any pull request.

Why it matters

Zero is heavily concurrent in the places where a race is both easy to introduce
and hard to see in review: the agent turn loop, streaming provider I/O, the
session store, cron, swarm mailboxes, and the cross-process lock paths in the
credential and OAuth stores. A data race in any of those is invisible to
go test ./..., to go vet, and to a reviewer reading a diff.

It also makes the contributor guidance unenforceable. A change can be reviewed
against a race-freedom expectation that nothing in the pipeline actually checks,
so the first time a race shows up is as a flake or a corrupted store on a user's
machine.

Cost

Test step durations on the most recent run of main (32547741559):

runner	duration
ubuntu-latest	3m33s
macos-latest	3m44s
windows-latest	4m39s

The Smoke (windows-latest) job is the current long pole at 9m29s. A race run
is typically 2-5x a plain one, so where the check is placed decides whether it
changes PR wall time or not.

Notes

-race needs cgo and a C toolchain. GitHub's hosted runners have one, so no
extra setup step is required on ubuntu.

Whether the check should block, and whether it should run on more than one
platform, is worth deciding alongside the first measured run: if the suite has
a pre-existing race, that surfaces immediately and is a separate fix.

[gnanam1990]

Verified on main. Confirmed exactly as reported, including both line references.

Makefile:21-22   test:
                     go test ./... -race -count=1

grep -rn -- "-race" .github/workflows/      -> no matches
grep -rn "go test"  .github/workflows/      -> ci.yml:79, pr-auto-review.yml:42,
                                               release-artifacts.yml:51  (all plain)
grep -rn "make test" .github/workflows/     -> no matches

So the target that declares race testing is never invoked, and -race appears nowhere in the pipeline. The race detector has not run on any pull request.

One thing I checked that the report does not claim, and it cuts both ways

I ran the detector against the packages the issue names as the risky ones:

go test -race ./internal/sessions/ ./internal/cron/ ./internal/swarm/ \
              ./internal/credstore/ ./internal/oauth/ -count=1
ok  (all five)

All clean. So this is a gap in the pipeline rather than a latent race — nothing is currently broken by it. I did not complete a full-suite race run, so I cannot speak for the other ~80 packages.

That makes the severity argument the one the report already makes, and I think it holds on its own: the value of the check is catching the race that gets introduced next, in code that is invisible to go test, to go vet, and to a reviewer reading a diff. Zero's concurrent surfaces — the turn loop, streaming provider I/O, the session store, cron, swarm mailboxes, cross-process credential locking — are exactly where that happens, and a race there first shows up as a flake or a corrupted store on a user's machine.

There is a second-order cost worth naming: #919 in this tracker is an intermittent CI failure that reproduces only on loaded runners. With no race job, the pipeline has no way to distinguish a scheduling flake from a genuine data race, so every intermittent failure has to be triaged by hand.

The report's cost analysis is the useful part of the discussion — where the check is placed (every PR, merge queue, or nightly) is the real decision, and it is a maintainer call rather than something this issue settles.