Stop Dependabot from raising Go SDK PRs against v3-3-test

[jason810496]

• related: Bump github.com/cappuccinotm/slogx from 1.4.2 to 1.5.0 in /go-sdk in the 3-3-go-sdk-dependency-updates group #71020 (review)
• related: Limit Dependabot Go module updates to security advisories only #70914, Scan Go SDK dependencies for known vulnerabilities in CI #70915

Why

Dependabot opened #71020 bumping a Go SDK dependency against v3-3-test. In review, jason810496 flagged that we shouldn't raise any Dependabot PRs for the Go SDK against release-test branches at all, since the Go SDK only ever releases from main.

What

• Rework the gomod//go-sdk Dependabot block targeting v3-3-test to match the default-branch block's security-only pattern (open-pull-requests-limit: 0, security-updates-only group), instead of raising routine version-update PRs.

Once this merges, #71020 should be closed manually — this config change doesn't retroactively close a PR Dependabot already opened.

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Sonnet 5)

Generated-by: Claude Code (Sonnet 5) following the guidelines

[Lee-W]

I'm a bit confused and would like to check how go-sdk and other sdk work with patch versions. Thanks!

[jason810496]

I'm a bit confused and would like to check how go-sdk and other sdk work with patch versions. Thanks!

Currently, only the Go SDK enable the depedentbot (Java, TS haven't but will). We restricted the Go SDK depedentbot focusing on the security advisories (not bump the version for minor or patch) for main.

Actually, I should make the v3-3-test one focus on security advisories only instead of dropping it.

[github-actions]

Backport failed to create: v3-3-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-3-test

You can attempt to backport this manually by running:

cherry_picker f6c19e4 v3-3-test

This should apply the commit to the v3-3-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.