fix(ci): run the suite before tagging a release

[mogita]

Ticket

CHA-2963

Problem

The release job tags, creates the GitHub Release and publishes on every push to main with no test gate in front of it, so a red suite still ships a tag. For Go that is permanent: proxy.golang.org caches a tag forever.

Its pending-release lookup also reads one page of closed PRs and filters the label client-side, then takes .[0]. A release that has slipped past that page reads as "nothing to release", and the job exits 0 without tagging.

Solution

• run_tests.yml: the test-and-build matrix, moved out of ci.yml unchanged (the job body is byte-identical) and exposed as workflow_call.
• ci.yml: calls it on pull_request. The push: main trigger is dropped, because otherwise a release push would run the integration leg twice at once against the shared d2sj6pudbhz7 app, which is what made php and net flake.
• release.yml: detect finds the pending release and verifies the go.mod major, tests runs the suite, release tags only after both. The label query now filters server-side and by base branch, matching the other five SDKs.

Workflow-level permissions drops to contents: read, with per-job grants.

How to verify

1. This PR's own checks: the six matrix legs report as ci / 👷 Test & Build … and are the same six that ran before.
2. On the next release, Release runs Detect pending release → Tests → 🚀 Tag and release. A failing suite leaves the tag uncreated.
3. On a normal push, detect prints "No pending release" and only Release PR runs.

Review instructions

Run the branch-protection PATCH before merging, not after. A reusable-workflow call reports as <caller job id> / <called job name>, and the six required contexts are currently the bare names, so this PR's own checks already report under the new names and its mergeable_state is blocked until the contexts move. Sending checks rather than contexts[] keeps the app_id: 15368 pinning the branch has today:

gh api -X PATCH repos/GetStream/getstream-go/branches/main/protection/required_status_checks \
  --input - <<'JSON'
{
  "strict": true,
  "checks": [
    {"context": "ci / 👷 Test & Build 1.19 & Integration", "app_id": 15368},
    {"context": "ci / 👷 Test & Build 1.20", "app_id": 15368},
    {"context": "ci / 👷 Test & Build 1.21", "app_id": 15368},
    {"context": "ci / 👷 Test & Build 1.22", "app_id": 15368},
    {"context": "ci / 👷 Test & Build 1.23", "app_id": 15368},
    {"context": "ci / 👷 Test & Build 1.24", "app_id": 15368},
    {"context": "👮 Conventional PR title", "app_id": 15368}
  ]
}
JSON

Every other open PR here stalls until it is rebased. #161, #127, #126, #105, #104, #73, #68 and #59 all run the old ci.yml on their heads, so they report the bare names and block on the new ones. strict=true already requires those rebases, but this turns a per-PR rebase into a fleet-wide one.

One trade-off worth knowing: with push: main gone, Codecov stops getting a report on every main commit and gets one per release commit instead. PR coverage still uploads on every run.

[mogita]

Two substantial findings, inline.