Add linting job in Workhorse pipeline to prevent using a too new Gitaly API version

Summary

To support independent deployment of Gitaly and Workhorse (as outlined in epic &20030), we need to prevent Workhorse developers from accidentally updating the Gitaly dependency to a version that is too new, which would break the ability to deploy Workhorse before Gitaly.

Problem

When Workhorse and Gitaly can be deployed independently, Workhorse must not depend on Gitaly APIs that don't exist in the currently deployed Gitaly version. If the Gitaly dependency in Workhorse is updated to a version newer than the deployed Gitaly servers, it could introduce calls to RPCs that don't exist yet, causing failures.

This issue addresses the same problem as #584284 but for Workhorse, which is a Go-based Gitaly client.

Proposal

Add a linting job to the Workhorse CI/CD pipeline that:

1. Monitors changes to the Gitaly dependency in go.mod (in the workhorse/ directory)
2. When the Gitaly dependency version is updated, compares:
   • Current Workhorse version
   • New Gitaly dependency version
3. Enforces the policy: Gitaly dependency must be one version behind Workhorse
4. Fails the pipeline if this constraint is violated

This would provide early feedback to developers during code review, preventing incompatible dependency changes from being merged.

Implementation Considerations

• Detect workhorse/go.mod changes in CI (e.g., using git diff on go.mod or go.sum)
• Parse and compare semantic versions of Workhorse and Gitaly dependency
• Define clear version comparison logic (e.g., Workhorse 17.7.0 should use Gitaly 17.6.x)
• Provide clear error messages when the lint check fails, explaining the version policy
• Consider edge cases (pre-release versions, patch updates, etc.)
• Leverage Go tooling for version parsing and comparison

Related Work

• Epic &20030 - Allow Gitaly Clients and Gitaly to be deployed independently
• #584284 - Similar linting for Rails (Ruby-based Gitaly client)
• &20030 (comment 2955060618)

Context

Workhorse is a Go-based Gitaly client that handles Git operations over HTTP, file uploads, and other performance-critical operations. Like Rails, it needs to maintain version compatibility with deployed Gitaly servers to enable zero-downtime upgrades in Kubernetes environments.