ci: move static-validation jobs off the trusted evalops-internal lane

[haasonsaas]

Summary

tag-release.yml and version-bump.yml are shared verbatim between
evalops/maestro and evalops/maestro-internal, and route to the trusted
evalops-internal lane whenever github.repository == 'evalops/maestro-internal'.
This PR updates that branch to evalops-private-ci (companion PR open on
maestro-internal for the same files).

policy/dual-cloud-runner-lanes.yaml in evalops/deploy forbids the
static_validation and audit_metadata_only workflow families on the
evalops-internal lane, and docs/operations/internal-runner-capacity.md
states the rule this PR enforces:

PR-only metadata checks and static validation should stay on the private
CI lane or GitHub-hosted fallback, not the trusted cluster lane.

tag-current-version and version-bump tag/commit/push a release branch
and open a PR via git and the GitHub API — no private GKE, GCP Secret
Manager, or Terraform access — so the internal-repo branch belongs on the
Hetzner-backed evalops-private-ci lane.

Found by the org-wide runner audit: evalops/deploy#7260

Jobs moved

• tag-release.yml :: tag-current-version (maestro-internal branch only)
• version-bump.yml :: version-bump (maestro-internal branch only)

Diff scope

runs-on: lines only, preserving the existing conditional expression
shape.

[haasonsaas]

Chief-of-staff correction: do not merge this in its current form. Routing static or metadata-only work from evalops-internal into evalops-private-ci moves load into the pool that is saturated today. Revise each job by resource need: fork-safe static validation goes GitHub-hosted; code-free metadata or reducer work goes evalops-runner-guard; private CI is allowed only with a named private network, secret, or identity dependency. Add a placement test and before/after queue evidence, then request readmission.