git-cli: PR merge-status and run-watch branch correlation unreliable on Gitea

[St0nefish]

Hit both of these while driving the ship flow against a Gitea remote (self-hosted). They make merge-watching hard to automate — the ship orchestrator couldn't tell whether a PR had merged, and run watch reported no CI when CI had actually passed.

1. PR merge-status fields are self-contradictory on Gitea

For a PR that was actually merged (merge commit on the base branch, source branch auto-deleted on the remote), git-cli pr show <N> returns:

{ "state": "merged", "merged": false, "mergeable": "false", "mergedAt": null }

Only state is correct. merged and mergedAt say "not merged," so a consumer checking the natural fields (.merged / .mergedAt) concludes the PR is still open. This persisted across many minutes (not a propagation lag) and across multiple PRs.

Repro: open a PR on a Gitea repo that auto-merges on green CI (the merge is done via POST /pulls/{n}/merge); after it lands, pr show reports the above.

Expected: merged: true + mergedAt: <ts> once merged, consistent with state. If Gitea's API genuinely omits these for the API-merge path, then run watch/pr wait/ship docs should state that state is the only reliable merge signal on Gitea.

2. run watch --branch can't correlate runs on Gitea (empty .branch)

git-cli run watch --branch <name> returns status: no-workflow ("CI workflow runs exist but none correlate to branch ... after 120s") even when a run did execute and succeed for that branch's head commit.

Root cause: git-cli run list returns runs with an empty .branch field on Gitea (the run object's keys are branch, duration, event, head_sha, id, started_at, status, url, workflow, but branch is blank). So branch-based correlation finds nothing. Matching on .head_sha works:

git-cli run list --limit 15 | jq -r '.[] | select(.head_sha|startswith("<sha>")) | "\(.status)"'
# -> success   (the run that `run watch --branch` reported as no-workflow)

Expected: populate .branch from the Gitea run payload, or have run watch fall back to head-SHA correlation when .branch is empty, so ship's "watch CI" step works on Gitea.

Environment

• git-cli 2.0.11
• Self-hosted Gitea remote
• Both reproduced repeatedly during a multi-PR ship session (homelab-admin).