fix: migrate module path to /v5 (v5.0.0 is currently unconsumable)

[mogita]

Problem

The `v5.0.0` tag was cut from a breaking change (add GetChannel, #123) but the Go module path was never bumped. `go.mod` at `v5.0.0` (and on `main`) still declares `module github.com/GetStream/getstream-go/v4`, and all 22 test files + `feedtest` import `/v4`.

Go requires a `/vN` suffix for major v2+. So today:

• `go get github.com/GetStream/getstream-go/v5` -> no such module (none declares `/v5`)
• `go get github.com/GetStream/getstream-go/v4@v5.0.0` -> invalid major/tag combination

Net: v5.0.0 is not consumable by any Go client, and `go get ...@latest` silently resolves to v4.2.2. The GetChannel endpoint that triggered the major bump is effectively stranded (only in v5.0.0+/main, which nobody can pull, and not in any v4 tag).

This PR

Bumps `go.mod` and every module self-import (tests + `feedtest`) to `/v5`. Library code is a single root package, so no production imports change. `go build ./...` and `go vet ./...` pass.

The `stream-chat-go` migration guide and the historical `MIGRATION_v3_to_v4.md` are intentionally left at `/v4` (the guide should track the released version and flip to `/v5` once a valid v5 is tagged).

Release decisions for the maintainer (not done here)

1. Re-tag v5. After merge, the current `v5.0.0` tag points at a `/v4` commit and stays broken. Because `/v5` was never served by the module proxy, cutting a fresh `v5.0.0` at the merged commit is clean (recommended); `v5.0.1` is the zero-risk alternative if you would rather never move a tag.
2. Retarget downstream once tagged: the migration guide (`/v4` -> `/v5`) and the `stream-backend` agent skill.
3. Add `MIGRATION_v4_to_v5.md` documenting the actual v4 -> v5 breaking change (GetChannel) for existing getstream-go users.
4. Guard the release automation. standard-version/release-please bumped the major from a `feat!` commit without the Go `/vN` module migration. This will recur on every future Go major across the generated SDKs unless a major bump is gated on the module-path migration.

[mogita]

Superseded by #130, which landed the same /v4 -> /v5 module path migration plus the migration-guide docs, released as v5.1.0 in #131. The diff here against current main is empty.

The deferred items from the description are resolved:

• Re-tag v5: dropped. v5.1.0 is already the first consumable v5, so reusing the v5.0.0 number would produce a tag whose content is newer than v5.1.0 while sorting below it. The v5.0.0 tag and GitHub release are deleted instead. Nothing was ever published for it (no proxy entry, no sum.golang.org record), so no checksum is invalidated and nobody can be pinned to it.
• Retarget downstream: docs done in fix: align go module path with the v5 major version #130; the stream-backend agent skill is updated in feat(stream-backend): server-side SDK migration skill agent-skills#55.
• MIGRATION_v4_to_v5.md and the release-automation guard: fix: v5 follow-ups: Version() prefix, migration guide, release major guard #134, which also fixes Version() returning a doubled v prefix.