chore(deps): bump steadybit kits and drop Go patch pin

[joshiste]

Bumps the steadybit kit modules to versions declaring go 1.26 and drops the exact-patch pin from the go directive, so 1.26.x patches are picked up automatically.

Also removes the redundant go_version override from ci.yml — the reusable extension CI now defaults to a floating 1.26, matching the floating golang:1.26-* Docker base images.

[claude]

Claude finished @joshiste's task in 2m 2s —— View job

---

Claude finished reviewing this PR

Todo:

• Check for previously unresolved Claude review threads (none found)
• Gather context (diff, go.mod, go.sum, ci.yml, extension-kit reusable workflow)
• Review changes for correctness, security, performance, concurrency issues
• Post final review

Summary

This is a clean, mechanical change: drops the Go patch pin (go 1.26.5 → go 1.26 in go.mod), removes the now-redundant go_version: '^1.26.5' input override in ci.yml, and bundles a routine bump of several steadybit/* dependencies (action-kit, discovery-kit, extension-kit) plus their transitive deps. go.sum changes are consistent with the go.mod bumps. No application source code is touched.

Finding

PR description doesn't match actual CI behavior. The description states that setup-go will read the version from go.mod via go-version-file, "configured in extension-kit reusable CI." I checked the current main branch of steadybit/extension-kit at .github/workflows/reusable-extension-ci.yml, and it does not use go-version-file — it still uses a go_version input (hardcoded default '1.26') passed straight to actions/setup-go's go-version field (lines ~26-28, 125-127, 331-333, 518-520):

go_version:
  type: string
  required: false
  default: '1.26'
...
      - uses: actions/setup-go@v7
        with:
          go-version: ${{ inputs.go_version }}

Removing the go_version override here works today only because the reusable workflow's hardcoded default ('1.26') happens to match the new go.mod directive (go 1.26) — not because CI is now dynamically reading go.mod. This isn't a functional bug in this PR (CI will resolve to the correct version right now), but it means:

• If go.mod's go directive is bumped again later without a matching update to extension-kit's default (or vice versa), the Go version used by CI will silently diverge from the one declared in go.mod.
• The change doesn't actually achieve what the PR title/description claims ("lets setup-go read the version from go.mod via go-version-file").

Worth either updating the PR description to reflect that this currently relies on the reusable workflow's default matching go.mod, or following up in extension-kit to actually switch to go-version-file so the described behavior is real.

No other correctness, security, or performance concerns found — this is otherwise a standard dependency/version bump.

Note: I was unable to run go build/go test in this sandbox (network/tool restrictions), so I couldn't independently verify the build against the updated go.sum. The SonarQube Cloud check on this PR already passed with 0 new issues, which is a reasonable proxy signal.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud