ci: guard privileged workflows so they cannot run in forks #6248

What

Kilo Cloud workflows have no canonical-repo guard, so a fork with Actions enabled will attempt to run them. Kilo-Org/kilocode has had the rule if: github.repository == 'Kilo-Org/kilocode' on its non-test workflows for a long time; Kilo Cloud never picked it up.

Why it matters

• Privileged workflows are reachable from a fork. deploy-production.yml, deploy-staging.yml, deploy-workers.yml, deploy-kiloclaw.yml, kilo-app-release.yml, extension-store-release.yml, redeploy-web.yml, and push-dev-kiloclaw.yml fail on missing repo secrets/vars when run outside Kilo-Org/cloud. Deploy/release actions should be unreachable outside the canonical repo, not merely fail on a missing secret.
• Scheduled/push automation fires in forks too. auto-docs.yml, bump-openclaw.yml, sbom.yml, setup-smoke.yml, and stale-prs.yaml act on shared state (webhooks, issue comments, PR closes) that only makes sense for the canonical repo.
• Noise. Contributors see failures in their fork that have nothing to do with their change.

For example, on 2026-09-16 run 35139264761 — a fork PR branch whose merge touched .github/workflows/* — failed with "This run likely failed because of a workflow file issue", and the fork's push/scheduled workflows would attempt the same privileged jobs.

Proposal

Mirror the kilocode rule: add if: github.repository == 'Kilo-Org/cloud' to the jobs of the workflows that must only run in the canonical repository, combined with any existing if condition.

Guarded: auto-docs, bump-openclaw, check-md-table-padding, codeql, deploy-production, deploy-staging, deploy-workers, deploy-kiloclaw, extension-store-release, kilo-app-release, promote-vercel-deployment, push-dev-kiloclaw, redeploy-web, sbom, setup-smoke, stage-vercel-deployment, stale-prs.

Intentionally not guarded: the pull-request validation workflows (ci.yml, extension-ci.yml, kilo-app-ci.yml, mobile-native-build.yml, chromatic.yml, trufflehog.yml). For pull_request events github.repository is the base repo, so a guard there is a no-op for normal CI and would only turn an approved fork-PR run into a wall of skipped jobs. This matches kilocode, which does not guard its test/typecheck workflows.

Not addressed here

Every fork PR also produces action_required runs. That is GitHub's repo setting Settings → Actions → General → Fork pull request workflows (approval required before fork workflows run) and cannot be suppressed from workflow code. If the intent is to stop those runs entirely rather than keep them approval-gated, it needs a settings change by a maintainer — e.g. restricting approval to first-time contributors.

A PR implementing the guard is coming.