fix: add -buildvcs=false to Linux container builds

[wesm]

Summary

• Add -buildvcs=false to the go build command in the build-linux job
• Fixes error obtaining VCS status: exit status 128 when building inside manylinux Docker containers where git safe.directory is not configured
• Version info is already stamped via -ldflags, so VCS stamping is redundant

Failed run: https://github.com/wesm/agentsview/actions/runs/23521504471

Test plan

• Tag v0.16.1 and verify both Linux builds succeed
• Verify wheels are published to PyPI

🤖 Generated with Claude Code

[roborev-ci]

roborev: Combined Review (c9b0498)

Summary Verdict: The changes update the release workflow to disable VCS stamping during Linux container builds and introduce no issues.

All agents agree the code is clean.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[roborev-ci]

roborev: Combined Review (4eb0d64)

Summary Verdict:
The changes introduce a high-severity release integrity issue by allowing incomplete PyPI publications if Linux wheel builds fail.

High

• Location: .github/workflows/release.yml:268-279
• Problem: Removing --require-all and turning the wheel smoke test into a
  conditional skip means the pypi job can now publish a tagged release even when the Linux wheel is missing. If build-linux flakes, that version becomes permanently incomplete on PyPI because the missing wheel cannot be uploaded later under the same version.
• Fix: Keep the GitHub release non-blocking
  if desired, but gate PyPI publication on the full expected wheel set being present, or fail the pypi job when the required Linux wheel is missing.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[roborev-ci]

roborev: Combined Review (4a38543)

Summary Verdict: The change attempts to decouple the release process from the build-linux job, but a flaw in the GitHub Actions condition prevents it from working as intended.

High

• Location: .github/workflows/ release.yml:188
• Problem: The new release job condition does not make build-linux non-blocking. In GitHub Actions, a job listed in needs still causes downstream jobs to be skipped when it fails unless the downstream if uses always(). With
  needs: [build-linux, build] and if: ${{ !cancelled() && needs.build.result == 'success' }}, release will still be skipped whenever build-linux fails, so the workflow does not actually implement the behavior described by the change.
• Fix: Change
  the condition to explicitly override failed/skipped dependencies, for example if: ${{ always() && !cancelled() && needs.build.result == 'success' }}, and then gate only the jobs that truly require build-linux on needs.build-linux.result == 'success'.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)