build: decouple the Go modules with a workspace so Dependabot PRs stay green

[pdettori]

Summary

remote-worker consumes gen/go through a local replace, and the proto job builds
both modules. Dependabot opens one PR per go.mod, so any bump to a gen/go dependency
left remote-worker/go.mod pinning stale indirect versions and CI failed with
go: updates to go.mod needed. Dependabot cannot fix that itself — the tidy has to land
in the same commit as the bump, and its branches are not maintainer-writable — so #210 had
to be bundled by hand into #211.

This adds a root go.work covering both modules. In workspace mode the go command
resolves one MVS across them, so a stale consumer go.mod no longer breaks the build and
the modules can be bumped independently, whatever layout Dependabot chooses.

Verification

Reconstructed the tree that failed in #210 — gen/go at grpc 1.83.2 / protobuf 1.36.12,
remote-worker/{go.mod,go.sum} restored to the pre-#211 commit b1af7bb — and ran the
proto job steps against it, before and after:

Check (stale remote-worker/go.mod)	Before	After
cd gen/go && go build ./... && go test ./...	pass	pass
cd remote-worker && go vet ./...	updates to go.mod needed	pass
cd remote-worker && go test -race ./...	fail	pass
cd remote-worker && go mod tidy -diff	drift	drift still reported
whole job	red	green, with an advisory warning

Also verified on a clean tree: every step green, both modules tidy. The workspace-coverage
guard was tested both ways — passes as-is, and fails when a go.mod is not in go.work.

Why not the directories: fix from the issue

Plural directories: is a shorthand here, not the fix — Dependabot still opens one PR per
directory. Bundling needs groups.<name>.group-by: dependency-name, which per the
options reference
"[a]pplies to version updates only" and creates "a single pull request for each
dependency". That would leave the security bumps this entry exists for (cf.
CVE-2026-84304 in #203) unbundled, and would split the deliberate grpc-protobuf cohort.
Separately, remote-worker carries protobuf as // indirect, which Dependabot's default
allow skips entirely. The config change here only collapses a duplicated group block.

A CI step that tidies and commits back to Dependabot's branch was also considered and
dropped: GITHUB_TOKEN is read-only on Dependabot pull_request events, so it needs a PAT
with write access triggered by dependency-PR content — a poor trade for a repo that pins
every action by digest and runs Scorecard.

Changes

• go.work — pinned go 1.25.0 to match both modules and CI's go-version-file
  (go work init writes the local toolchain instead).
• .gitignore — go.work.sum; the checksum database still verifies downloads, so this
  avoids a fourth sum file to keep in sync.
• ci.yml — blocking check that every tracked go.mod is listed in go.work (a module
  left out would silently reintroduce the failure), plus an advisory go mod tidy -diff.
  Failing on tidiness would put the coupled bumps back in the red, and neither module is
  consumed externally, so it is hygiene rather than correctness.
• remote-worker/Dockerfile — copies go.work; that build runs from the repo root and
  would otherwise resolve each module alone and still hit a stale go.mod. Not built in CI
  (build.yaml covers the root Dockerfile, sandbox.Dockerfile, echo-target), so this
  was latent rather than breaking.

No dependency versions change, so there is no new CVE surface.

Closes #212

Assisted-By: Claude Code