ci: go vet/lint steps don't use the per-module loop convention [mcp part]

[cristim]

Split from LeanerCloud/cloud-commitments-cli#1478 (cross-component issue, monorepo split)

ci.yml's three core code-health checks silently skip every module except the root one, in a repo that has been multi-module (go.work) for some time. In a Go workspace, a bare go vet ./... (or go test ./..., or a bare golangci-lint run) from the repo root only expands to packages in the current module. go.work only affects cross-module dependency resolution, not what ./... expands to.

The govulncheck and gosec steps already handle this correctly, looping for mod in <every module>; do (cd "$mod" && <tool> ./...); done. The same fix was never applied to go vet, unit tests, integration tests, or golangci-lint.

Mirror the govulncheck/gosec per-module loop for the go vet, unit-test, integration-test, and golangci-lint steps.

Scope for this repo (verified live against cloud-commitments-mcp main)

cloud-commitments-mcp is a single-module repo: go.work only declares use .. Unlike cloud-commitments-go and cloud-commitments-platform, there is currently no second module for go vet/golangci-lint/go test ./... to silently skip — a bare ./... from root already covers everything (the unit-test and integration-test steps already use for mod in .; go vet and the lint action run bare, which is functionally equivalent to the loop for a single module).

So the failure mode this issue describes does not currently reproduce here. Filing this as a consistency/hardening item, not a live coverage gap: the go vet step and the lint step are the only two CI checks in this repo that don't follow the for mod in ... loop convention used by unit tests, integration tests, govulncheck, and gosec. If this repo ever gains a second module (e.g. a separate tools/ or docs/ module), those two steps would silently regress into exactly the bug described in the parent issue, with nothing catching it.

Acceptance criteria

• go vet and the golangci-lint invocation are rewritten to use the same for mod in . loop pattern as the unit-test/integration-test/govulncheck/gosec steps, for consistency and to guard against a silent regression if a second module is added later.
• No behavioral change expected today (single module); confirm go vet/lint output is unchanged before and after.

[cristim]

Merged in #36 at b94f5d4c2ee6c4a35aa4b9fcc65a3119a1fa3e39.

Post-merge verification on that exact tree:

• Entire tree matches independently reviewed f7a0b52fd6fd22354d90443f4e5a0505b13f94f1.
• Executed the actual YAML vet/lint blocks with Go 1.26.6 and golangci-lint 2.10.1. Config validation, lint and vet pass; diagnostics match baseline apart from module banners.
• Five fixture-based shell probes pass for invocation arguments, working directory, cache and failure propagation. Config-validation failure prevents lint execution.
• Native actionlint and supplemental offline zizmor pass. Checkout is clean. Pre-merge race tests, build and normal hooks also passed.

The issue's loop-consistency criteria are satisfied. This single-module repository has no product runtime behavior change or newly expanded package coverage; future modules still require updating the explicit lists. Local act simulation timed out fetching actions, as disclosed in the PR. Main-branch CI monitoring remains with the coordinating session.

Recommendation: keep this issue closed. Follow-up issues: none; no separate defect found.