Check client / agent versions over RPC

[llogen]

Verify dutctl client ↔ agent version compatibility

The dutagent now bakes its version from the git tag and advertises it on every RPC response. Clients compare it against their own version and react to the difference, so an incompatible pairing is caught immediately instead of failing later with a confusing protocol error.

Changes

• Version baked from git. Release, CI, and task builds inject the tag via -ldflags "-X .../buildinfo.buildVersion=<tag>". buildinfo.Semver() resolves it in order: injected build version → the module version from debug.ReadBuildInfo() (so a plain go build still gets a real, git-derived version) → the release-please constant as a last-resort fallback. dutagent -v now reflects this.
• Always-on advertisement. The new pkg/versioncheck adds a connect server interceptor that stamps the agent's version onto the X-Dutctl-Version header of every RPC (unary and the streaming Run); the dutagent registers it.
• Client-side check. A connect client interceptor reads that header and compares it against the client's own version, once per connection; the dutctl CLI registers it.
• Removed the dedicated Version RPC — superseded by the always-on header (dropped from the proto, generated code, handler, and tests).

Compatibility policy

• Major differs → error; the call fails with FailedPrecondition
• Minor differs → warning
• Pre-release tag differs only (e.g. 1.0.0-alpha.1 vs 1.0.0-alpha.5) → warning
• Unparsable / dev / untagged version → warning (never errors)
• Patch differs only, or identical → silent

The check runs agent→client: the agent advertises, the client enforces. The interceptors are exported so other dutctl clients can adopt them.

Testing

• Unit tests for the classifier plus an in-process connect round-trip covering the header, minor→warn, and major→error.
• Verified end-to-end with an agent and clients built at different baked versions: patch → silent, minor → warning, major → failed call.
• go test ./..., go vet ./..., and golangci-lint run all pass.

[jenstopp]

I like the Interceptor mechanic and using the headers. Just the right tool for that purpose.

Which side should run the check?
The hard, authoritative check belongs to the agent. The agent is entity that must guard its own contract, and it's the only side that can actually reject. A client can decline to proceed, but only the agent can refuse to execute. So:

Generally, both, the client and the agent should include their version in the header

Agent (enforcement): The interceptor reads the client version from the request header and, on incompatibility, returns, e.g., connect.CodeFailedPrecondition together with helpful message before any module runs.

Client (advisory only): Read the agent version off the response header and, on mismatch, print a friendly warning ("agent is newer, please upgrade the client"). And maybe extended logic before v1.

Also check if the dutserver code needs to be adapted to reflect that behavior