[bug] Existing integration branches are reused without proving the recorded base

[coygeek]

[bug] Existing integration branches are reused without proving the recorded base

Summary

When DeployBot creates a cumulative integration PR, it creates refs/heads/{integration branch} at the current base SHA. If GitHub reports that the reference already exists, DeployBot silently continues and merges the frozen source heads into whatever commit that existing branch currently points to.

The integration marker then records the current base_sha, even though the actual integration branch may have been created from an older base or contain stale partial merges from a prior attempt.

Evidence

• create_integration_pull_request() computes base_sha = self.base_sha() in src/agent_merge_queue/cli.py line 1049.
• It tries to create refs/heads/{branch} at base_sha in lines 1050-1060.
• If the API error contains Reference already exists, it ignores the error and continues in lines 1061-1063.
• It then merges each source head into that existing branch in lines 1065-1088.
• It writes an integration marker containing the current base_sha and merged_heads in lines 1121-1129.
• The official Git documentation defines a branch head as a named reference to the commit at the tip of a branch: https://git-scm.com/docs/user-manual/2.54.0.html#Documentation/user-manual.txt-head.
• The official Git documentation explains that a merge applies changes since the branches diverged and creates a merge commit with parent tips: https://git-scm.com/docs/user-manual/2.54.0.html#Documentation/user-manual.txt-merge.
• The official Git documentation explains merge-base/common-ancestor semantics in https://git-scm.com/docs/git-merge-base, and ancestor reachability in https://git-scm.com/docs/user-manual/2.54.0.html#Documentation/user-manual.txt-reachable.

Impact

An integration PR can stop being a faithful cumulative test of "these frozen heads merged onto this frozen base":

• If the branch exists from an earlier base, the integration marker can claim a newer base_sha that is not actually an ancestor of the integration branch.
• If a previous attempt partially merged some heads, a rerun may merge the remaining heads onto stale partial state and report an inaccurate merged_heads list.
• If the base branch moved, DeployBot may omit the latest base changes from the cumulative validation PR while still presenting the PR as the current batch.

That undermines the purpose of integration mode: proving that a frozen batch works together on the intended base.

Proposed fix

• On Reference already exists, read the branch ref before continuing.
• Require one of these safe states:
  • the existing branch has a valid DeployBot integration marker for the same active batch_id, same base_sha, and same expected source heads, or
  • the branch is reset/updated back to the freshly computed base_sha before replaying merges.
• Make replay idempotent by treating already-contained source heads as merged only after proving ancestry, rather than relying on a fresh API merge call.
• Add regression tests for:
  • existing integration branch on an older base is rejected or reset.
  • existing integration branch with mismatched marker is rejected.
  • rerun with same branch/base/heads is idempotent and does not lie in the marker.

Verification

• python3 -m pytest tests/test_cli.py -q
• python3 -m pytest -q