canary-rollout PROMOTE fails for cross-repo (#482) agents: uses local 'git tag -f', not host gh-api (companion to #1049)

🔴 P1 — cross-repo agents can be evaluated but NOT promoted. #1049 made tag reading host-aware, but the promote write path still moves tags with local git. A gated manual promote of a ready reusable:
`gh workflow run canary-rollout.yml -f command=promote -f agent=dependabot-automerge -f dry_run=false` → gate said PROMOTE, then:

advancing dependabot-automerge/stable -> b7e6b67063f4
fatal: cannot update ref 'refs/tags/dependabot-automerge/stable': trying to write ref
  'refs/tags/dependabot-automerge/stable' with nonexistent object b7e6b67063f4b5673ca6955b2630b315adc1ccd3
##[error]exit code 128

Root cause

cmd_promote does git tag -f "$agent/$frontier" "$cand" && git push --force origin "$agent/$frontier" — local-checkout tags pushed to THIS repo's origin (.github-private). For a cross-repo agent (host: petry-projects/.github), the candidate commit b7e6b670 isn't in the local object DB (it's on .github), and the channel tag lives on .github, not here → git update-ref fails, and even if it didn't, it'd write to the wrong repo.

Fix

For host ≠ this repo, perform the promote against host via the existing primitive — scripts/cut-release.sh <agent> <version> --channel <target> --promote --push already does the host-aware gh-api channel move (#959/#992) using the App token. Delegate to it (or replicate its gh_move_tag against host). Keep the local git tag -f path only for this-repo agents (dev-lead, pr-review). Same split #1049 added for reads. Add a bats/integration case: promoting a cross-repo agent must move the tag on .github, not fail on a nonexistent local object.

Impact: none of the 6 #482 reusables can be promoted until this lands — the 2 currently gate-PROMOTE (dependabot-automerge, dependabot-rebase) are stuck. Companion to #1049 (reads) — introduced with the promote logic in #1002/#1026; --promote primitive from #959/#992.

Refs #1049, #1002, #1026, #959, #992, #1045.

Dev-Lead Implementation Plan

Issue: #1054 — canary-rollout PROMOTE fails for cross-repo (#482) agents: uses local 'git tag -f', not host gh-api (companion to #1049)

Scope

Make cmd_promote in scripts/canary-rollout.sh host-aware: for a cross-repo agent (host ≠ this repo) move the <agent>/<frontier> channel tag on host via the GitHub API (mirroring cut-release.sh's gh_move_tag / the #1049 read-path split), keeping the local git tag -f+git push path only for this-repo agents (dev-lead, pr-review).

Implementation Checklist

Add _gh_move_tag <repo> <tag> <sha> helper to scripts/canary-rollout.sh (force-move if exists, create if not — mirrors cut-release.sh gh_move_tag)
Branch the write path in cmd_promote: cross-repo → _gh_move_tag "$host" "$agent/$frontier" "$cand"; this-repo → existing git tag -f + git push --force origin
Make the --dry-run output host-aware for the cross-repo case

Tests to Write

tests/canary_rollout.bats: promoting a cross-repo agent moves the channel tag on host via gh api and exits 0 (regression: the old local git tag -f path fails on the nonexistent local object)
tests/canary_rollout.bats: cross-repo promote --dry-run prints the host-aware move and touches neither git nor the API

Test Command

bats tests/canary_rollout.bats (full: git ls-files 'tests/*.bats' | xargs bats)

Dev-Lead: Implementation Complete

Plan Execution

Added _gh_move_tag <repo> <tag> <sha> helper to scripts/canary-rollout.sh (force-move if the ref exists via PATCH .../git/refs/tags/<tag>, else create via POST .../git/refs) — mirrors cut-release.sh's gh_move_tag (feat: wire cut-release.sh cross-repo publish via gh api (#872) #959/feat(cut-release): add --promote for ring-to-ring channel moves (#501) #992)
Branched the write path in cmd_promote: cross-repo agent (host ≠ THIS_REPO) → _gh_move_tag "$host" "$agent/$frontier" "$cand"; this-repo agents (dev-lead, pr-review) keep the local git tag -f + git push --force origin path — the same split canary-rollout evaluate mis-reports all 6 cross-repo (#482) reusables as 'fully rolled out' — reads local tags, not .github #1049 added for reads
Made --dry-run host-aware for the cross-repo case
Added 2 regression tests to tests/canary_rollout.bats

Test Results

tests/canary_rollout.bats: 54 ok / 0 not ok
  ok 53 orchestrator: promoting a cross-repo agent moves the channel tag on host via gh api, not local git (#1054)
  ok 54 orchestrator: cross-repo promote --dry-run shows the host move but touches neither git nor the API (#1054)

Full lint.yml bats set (40 files): 1023 ok / 0 not ok
dev-lead-lint.sh (shellcheck @ warning on 87 files + agent frontmatter): all checks passed
shellcheck -S warning scripts/canary-rollout.sh: clean

Files Changed

scripts/canary-rollout.sh: new _gh_move_tag host-aware channel-move helper; cmd_promote now moves the channel tag on host via the GitHub API for cross-repo agents instead of local git tag -f/git push (which failed with nonexistent object / wrong-repo, exit 128)
tests/canary_rollout.bats: _crossrepo_promote_stub + 2 tests. The git stub deliberately fails (exit 128) on tag -f/push, so a regression to the local path re-breaks the test; the gh stub logs the host API move and the test asserts it targets git/refs/tags/auto-rebase/stable at the candidate commit

Notes

The regression test proves the move goes through the host API by (a) making local git tag -f/push fail loudly and (b) asserting the logged PATCH .../git/refs/tags/auto-rebase/stable carries the candidate SHA — exactly the "must move the tag on .github, not fail on a nonexistent local object" case requested.
Scope kept to the promote write path per the issue. cmd_rollback has the same local-git assumption (its git rev-parse refs/tags/$agent/$to read and git tag -f write would also fail for a cross-repo agent), but that is out of scope here — worth a follow-up issue if cross-repo rollback becomes a requirement.