Add weekly Dependabot updates for Go modules

[vasukinjfrog]

Summary

Two things, and the second one explains why an Azure file is touched in a Dependabot PR.

1. Weekly Dependabot updates for Go modules — adds .github/dependabot.yml:

• Runs weekly (Mondays) against the gomod ecosystem at /, opening PRs from dependabot/go_modules/* branches against main with go.mod / go.sum changes.
• Minor and patch bumps are grouped into one weekly PR; majors still open individually for review. Same pattern as jfrog-cli and jfrog-client-go.
• This repo already got ad-hoc Dependabot security PRs (Bump golang.org/x/crypto from 0.38.0 to 0.45.0 #21, Bump golang.org/x/crypto from 0.45.0 to 0.52.0 #92) but had no config, so scheduled version updates were never running.

2. A PR gate so a dependency bump can't silently break the build — adds .github/workflows/go.yml, a go-mod-test-build check that runs on every PR:

Step	What it catches
go mod verify	module contents don't match go.sum
go mod tidy + git diff --exit-code	go.mod / go.sum drifted from the real import graph
go test ./...	compile errors, vet findings, failing unit tests
make -C build build-all	the shipped linux amd64 + arm64 binaries no longer build

Go's own guarantees stop short of "these upgrades work together". go.sum proves integrity (same bytes) and MVS makes resolution deterministic (same versions every time), but neither proves two semver-compatible bumps are compatible in practice. Compiling and testing the resolved graph is what proves that, which is what this check does.

Why internal/handlers/azure.go is in this PR

Adding the gate made go test ./... fail immediately on main. Since Go 1.10 go test runs a subset of vet (including printf), so this is go test itself failing, not an extra lint step:

internal/handlers/azure.go:85:25: non-constant format string in call to fmt.Errorf
internal/handlers/azure.go:138:25: non-constant format string in call to fmt.Errorf
internal/handlers/azure.go:146:25: non-constant format string in call to fmt.Errorf
FAIL	jfrog-credential-provider/internal/handlers [build failed]

These were not style findings. The three lines looked like this:

fmt.Errorf("Calling azure oidc token failed: %v" + err.Error())

The + binds before the call, so err.Error() was concatenated onto the format string rather than passed as an argument — leaving fmt.Errorf with a %v verb and zero arguments. Running the old and new forms side by side against a realistic Azure transport error:

OLD: Calling azure oidc token failed: %!v(MISSING)Get "https://login.microsoftonline.com/oauth2/v2.0/token?scope=api%!A(MISSING)%!F(MISSING)%!F(MISSING)aud%!F(MISSING).default": dial tcp: i/o timeout

NEW: calling azure oidc token failed: Get "https://login.microsoftonline.com/oauth2/v2.0/token?scope=api%3A%2F%2Faud%2F.default": dial tcp: i/o timeout

Two separate defects in the old output:

1. The dangling verb renders as %!v(MISSING).
2. Because the error text lands in format-string position, the URL-encoded characters in the Azure token endpoint (%3A, %2F) are themselves parsed as format verbs and mangled into %!A(MISSING) / %!F(MISSING).

So on a node where Azure token acquisition is failing, the log line an operator has to debug from had an unreadable endpoint. That is exactly the bug class the "non-constant format string" check exists to catch: remote-influenced text reaching format-string position.

The fix passes the error as an argument and uses %w instead of %v, which also restores unwrapping (errors.Is / errors.As) — the old form unwrapped to nil, the new form unwraps to the original error. Two of the three messages were also lowercased to match Go's convention that wrapped error strings aren't capitalized; that part is cosmetic and can be dropped if reviewers prefer a strictly minimal diff.

Leaving these unfixed would have meant either a permanently red go-mod-test-build on every future Dependabot PR, or turning the check off with go test -vet=off — both of which defeat the point of the gate.

Test plan

• Confirm this PR's go-mod-test-build check is green.
• Merge to main — Dependabot only reads dependabot.yml from the default branch.
• Confirm Insights → Dependency graph → Dependabot lists a gomod version-updates config.
• After the first Monday run (or via Dependabot "Check for updates"), confirm a PR appears from a dependabot/go_modules/* branch and that go-mod-test-build runs on it.
• Recommended: in branch protection for main, mark go-mod-test-build as a required status check, otherwise a red Dependabot PR can still be merged.