Detect stale nested-module pins before release

[reyortiz3]

Summary

This is the process fix for the bug found while chasing why toolhive-core@v0.0.46's redis package failed to build downstream (redisconn.Config.PoolSize/.MaxActiveConns unknown field). Root cause: #287 added those fields to redisconn, but the root and provider go.mod files kept their redisconn v0.0.1 requirement, and scripts/validate-release.sh never noticed — it only checks that the tag referenced by a pin exists, not that the pinned version still matches the current tree. So root releases v0.0.44, v0.0.45, and v0.0.46 all shipped pinning a redisconn version that no longer matched the code actually in the tree, and every downstream consumer resolving redisconn from the module proxy got stale, incompatible package content.

Changes:

• scripts/validate-release.sh: after confirming a required redisconn(/aws|azure|gcp) tag exists, additionally diffs the current working tree for that submodule directory against the tag's tree. Any drift fails the release preflight with a clear message to cut a new tag and update the pin first.
• scripts/testdata/release-stale-pin/go.mod + scripts/test-validate-release.sh: regression test using the real, currently-existing redisconn/v0.0.1 tag, which now correctly fails validation because redisconn/ has genuinely diverged from it since feat(redis): add configurable connection pool bounds #287 (i.e., this test documents and locks in a fix for the actual incident).
• .github/workflows/test.yml: test-validate-release.sh was only ever run through the local task redisconn-modules command, never in CI. Wired it into the "Check standalone Redis modules" step (with fetch-depth: 0 on checkout so nested-module tags are available for the tag-existence/drift checks).

This PR previously also carried the redisconn/{aws,azure,gcp} version-pin bump from #292 with their dev-only replace directives removed. That's been reverted: Renovate had already bumped the version pins to v0.0.2 on main (#293) while keeping the replace directives, matching the established precedent from the original v0.0.1 release (#276), which also kept replace in place deliberately — it's a no-op for downstream consumers (Go ignores a dependency's own replace directives) and preserves local monorepo development convenience. Removing it was a mistake on my part; #292 is closed as fully superseded by Renovate, and this PR is now scoped to just the validation fix.

Test plan

• ./scripts/test-validate-release.sh passes, including the new regression case
• Manually confirmed ./scripts/validate-release.sh v1.2.3 run against scripts/testdata/release-stale-pin/go.mod now fails with: go.mod requires github.com/stacklok/toolhive-core/redisconn v0.0.1, but redisconn has changed since redisconn/v0.0.1 was tagged; ...
• Confirmed ./scripts/validate-release.sh redisconn/v0.0.2 (the tag just cut to fix the live incident) still passes cleanly
• Confirmed this branch now has zero diff against main for redisconn/{aws,azure,gcp}/go.mod and go.sum

Related

• redisconn/v0.0.2 tag: cuts the missing release for the code already in redisconn/.
• A follow-up root release-preparation PR will pin root go.mod's redisconn/{aws,azure,gcp} requirements to v0.0.2 (once those submodules are tagged) ahead of a v0.0.47 tag — which this new check will now correctly gate.

🤖 Generated with Claude Code