STAC-25459 Wire inv check-mod-tidy into CI, gated on the godeps cache hash

[LouisParkin]

What

Wires the existing, never-referenced inv check-mod-tidy task (tasks/go.py:302) into the GitHub Actions lint workflow as a Go module tidiness (go.mod / go.sum) job.

Why

stackstate-agent has never verified module tidiness in CI — not on GitLab, not on GitHub. This is a pre-existing gap, not a regression from the STAC-25429 cache image:

• inv deps (tasks/go.py:148) is only download_go_dependencies. It does not tidy. (inv deps-vendored does, but that is a different task and is not what CI ran.)
• The go mod tidy that used to sit in the GitLab deps_deb reconcile was a bare YAML line that mutated the tree. It never failed a pipeline on untidiness. The only surviving reference is commented out inside the dead deps_rpm job (.gitlab-ci-agent.yml:104).
• inv check-mod-tidy already exists and is a real gate — go work sync, then per-module go mod tidy plus git diff --exit-code go.mod go.sum, then raise_if_errors. It was simply never called by any CI config.

How it is gated

The job is skipped when the godeps cache image already exists.

The cache tag is a sha256 over exactly **/go.mod, **/go.sum, go.work, go.work.sum and modules.yml (plus the Dockerfile, the metadata script, and the base image tag). So image_exists == true means those files are byte-identical to a tree this check has already passed on — the content-addressed tag doubles as a cached verdict. The check therefore costs nothing on the large majority of PRs, which do not touch the module graph, and runs exactly when the graph moves.

Known blind spot, documented in the job comment: a source-only change that removes the last import of a dependency leaves a stale require without touching any hashed file, so the job stays skipped. That does not break builds. A scheduled force_mod_tidy dispatch would cover it if we decide we want that.

Placement

The job lives in the caller (lint-and-unit-tests.yml), not in the reusable godeps-cache.yml, because that reusable workflow is called by both lint-and-unit-tests.yml and build-binaries.yml — a job added inside it would run twice per PR. It consumes the reusable workflow's existing image_exists and ci_image outputs.

Validation

workflow_dispatch carries a force_mod_tidy boolean so the gate can be exercised against an unchanged module graph (the current manifests are already baked, so image_exists is true and the job would otherwise skip).

• zizmor --collect=workflows,actions,dependabot . — no findings
• Forced dispatch run against this branch

Jira: https://stackstate.atlassian.net/browse/STAC-25459