fix: v5 follow-ups: Version() prefix, migration guide, release major guard

[mogita]

Follow-ups to the v5 major, split out of #133 (which is now empty: #130 landed the module path fix and #131 shipped it as v5.1.0).

1. MIGRATION_v4_to_v5.md

v4 -> v5 had no upgrade doc. The actual breaking surface is small, and it was verified by compiling a probe against v4.2.2 and v5.1.0 rather than read off the commit message:

• AppResponseFields.ModerationAudioFileEnabled removed.
• ModerationDashboardPreferences.AnalyzeMaxImageSizeBytes, .AnalyzeMaxKeyframeSizeBytes, .WebhookHeaderClientRequestIDKey removed.
• CheckResponse is no longer comparable with ==: it gained TriggeredRules []TriggeredRuleResponse. This propagates to StreamResponse[CheckResponse].

Everything else in v4 -> v5 is additive. Note the v5.0.0 release notes claimed the Video CallResponse was affected by the moderation CallResponse rename; it is not, and the guide says so. README now links both major-upgrade guides.

2. Release guard in initiate_release.yml

The v5.0.0 hole exists because the release workflow happily cut a v5 tag from a tree whose go.mod said github.com/GetStream/getstream-go/v4. Go rejects that combination, so the tag was dead on arrival and @latest silently stayed on v4.2.2 until v5.1.0.

The new step compares the requested major against the /vN suffix in go.mod and fails the workflow before the changelog is generated. Logic checked against: v5.1.0 + /v4 (the historical bug, fails), v6.0.0 + /v5 (fails), v5.2.0 + /v5 (passes), v2.0.0 + no suffix (fails), v1.4.0 and v0.3.0 + no suffix (pass), v10.0.0 + /v10 (passes), v10.0.0 + /v1 (fails).

3. Version() returned vv5.1.0

versionName already carries the leading v (the release workflow writes the tag verbatim), so "v" + versionName doubled it. Long-standing: v4.2.2 had it too. versionHeader() and the X-Stream-Client header were never affected.

4. The v5.0.0 tag and release are deleted

Nothing was ever published for that version: proxy.golang.org 404s it and sum.golang.org has no entry, so there is no checksum to invalidate and nobody can be pinned to it. Re-tagging it at main was the alternative and was rejected: it would produce a v5.0.0 containing more code than v5.1.0 while sorting below it.

The two CHANGELOG compare links that pointed at the deleted tag are repointed, and the 5.0.0 section now says where its contents shipped.

Verification

make test-unit passes, go build ./... and go vet ./... clean, make lint reformats nothing, workflow YAML parses.