CD pipeline fails on any fork push — pre-release job requires tags that forking doesn't copy

What happens

Any push to develop/master on a fork of this repo triggers cd.yml, and the pre-release job fails immediately:

LATEST_TAG=$(git tag -l 'v[0-9]*.[0-9]*.[0-9]*' --sort=-version:refname | grep -v '-' | head -1)
::error::No stable release tag found

Why

Forking a repo doesn't copy tags, and a plain git fetch/gh repo sync on a fork doesn't pull them either — so any fork ends up with zero v*.*.* tags. The pre-release job's version-computation step hard-requires at least one, so it can never succeed on a fork, regardless of what the push actually contains. I hit this simply by adding an unrelated workflow file to my fork's develop branch — first push, immediate red X.

The rest of the pipeline (build-prerelease, release-please, build-release, update-latest-tag) already cascades to skipped correctly once its needs.*.outputs are empty — only the two entry-point jobs (pre-release, release-please) actually attempt to run and fail on a fork.

Suggested fix

Guard both entry-point jobs in cd.yml with github.repository_owner == 'rtk-ai' (or equivalent), so the release/CD pipeline only ever runs on this repo, not on forks. Verified locally on my own fork that this fully resolves it — the same push that previously failed reports skipped instead, with no behavior change on the real repo (the added condition is already true there).

Happy to open a PR with this change if that's the preferred way to receive it — wanted to check first since I wasn't sure whether CI/workflow changes go through issues first here.

Start in cd.yml by inspecting the pre-release and release-please entry-point jobs and their existing conditions. Add the repository-owner guard to both, then verify that pushes from forks skip those jobs while pushes in the rtk-ai repository retain the current behavior.