[Bug]: transports/v2.0.0 tag is unusable via `go get` — module path missing required `/v2` suffi

Prerequisites

• I have searched existing issues and discussions to avoid duplicates
• I am using the latest version (or have tested against main/nightly)

Description

go get github.com/maximhq/bifrost/[email protected] fails outright - the Go toolchain refuses to fetch it, so the release cannot be consumed as a Go module dependency at all.

The transports/v2.0.0 git tag exists (points at 9537b2fadf42af90eb34ed47d3d4252e1beff4a0), and docs.getbifrost.ai/migration-guides/v2.0.0 / docs.getbifrost.ai/changelogs/v2.0.0 document it as a real, shipped release with breaking changes (notably the new HTTPTransportPreAuthHook phase from #6375). But the go.mod checked in at that tag still declares:

module github.com/maximhq/bifrost/transports

Per Go's semantic import versioning rules, any v2+ release must have its module path suffixed with the major version (.../transports/v2). Since this tag's go.mod wasn't updated to declare that path, both the Go module proxy and go get treat v2.0.0 as an invalid version under the existing (implicitly v0/v1) import path, and reject it.

Steps to reproduce

1. mkdir /tmp/repro && cd /tmp/repro && go mod init repro
2. go get github.com/maximhq/bifrost/[email protected]

Also reproducible directly against the module proxy, no local Go toolchain needed:

curl -s https://proxy.golang.org/github.com/maximhq/bifrost/transports/@v/v2.0.0.info curl -s https://proxy.golang.org/github.com/maximhq/bifrost/transports/v2/@latest

Expected behavior

go get github.com/maximhq/bifrost/[email protected] succeeds and pulls the v2.0.0 code, matching what the migration guide and changelog describe as the current release.

Actual behavior

$ go get github.com/maximhq/bifrost/[email protected] go: github.com/maximhq/bifrost/[email protected]: invalid version: module contains a go.mod file, so module path must match major version ("github.com/maximhq/bifrost/transports/v2")

Affected area(s)

Transports (HTTP), Core (Go)

Version

v2.0.0 transports

Environment

- OS: macOS 14.5 (darwin/arm64) - reproduces independent of OS/local Go version, since it's a module-proxy-level version-resolution failure
- Go: reproduced with go1.26.4 and go1.27.0
- Bifrost components and versions: transports (v2.0.0 tag), core v1.8.3, framework v1.6.0 - all pulled from the same v2.0.0 release train per the changelog; only transports is affected

Relevant logs/output

$ go get github.com/maximhq/bifrost/[email protected]
go: github.com/maximhq/bifrost/[email protected]: invalid version: module contains a go.mod
file, so module path must match major version ("github.com/maximhq/bifrost/transports/v2")

$ go get github.com/maximhq/bifrost/transports/[email protected]
go: github.com/maximhq/bifrost/transports/[email protected]: invalid version: transports/go.mod has
non-.../v2 module path "github.com/maximhq/bifrost/transports" (and .../v2/go.mod does not exist)
at revision transports/v2.0.0

$ go get github.com/maximhq/bifrost/transports@latest
go: added github.com/maximhq/bifrost/transports v1.6.11   # silently ignores v2.0.0 entirely

The only way to get the actual v2.0.0 code today is to bypass semver and pin the raw commit, which resolves to a synthesized v1-family pseudo-version instead of v2.0.0:

$ go get github.com/maximhq/bifrost/transports@9537b2fadf42af90eb34ed47d3d4252e1beff4a0
go: added github.com/maximhq/bifrost/transports v1.6.12-0.20260826193051-e4a30d6041c0

Regression?

Not a regression in behavior - every prior transports release (through v1.6.11) installs fine via go get. This is the first release where the module tagging itself is broken, specifically because it's the first attempt at a v2 major bump.

Severity

High (major functionality broken)