create-pr: base_commit from Stage 1 may become unreachable after target branch force-push

[jamesadevine]

Problem

When self.base_commit is present (recorded at patch generation time), it's used as "parents": [base_commit] in the ADO Push API payload. The merge-base is by definition an ancestor of the target branch, so this is semantically correct.

However, if the target branch was force-pushed after Stage 1 ran, the merge-base SHA might no longer be reachable in ADO's history — the push would fail with a cryptic HTTP 400.

The existing fallback (resolving live target branch HEAD when base_commit is None) doesn't help here because base_commit is Some.

Suggested Fix

If the push fails with a 400 and base_commit was from Stage 1, retry by falling back to the live ADO refs API resolution (same as the None path).

Context

Low probability in practice — requires a force-push to the target branch between Stage 1 and Stage 2. But worth checking first if unexpected 400 errors appear in production.

Identified in PR #155 review.

[jamesadevine]

After investigation: the base_commit is a merge-base (ancestor of the target branch). For this to become unreachable, someone would need to force-push the target branch to a completely rewritten history AND have ADO garbage-collect the old objects — all in the minutes between Stage 1 and Stage 2. This is effectively impossible in normal workflows.

The existing fallback path (resolving live HEAD when base_commit is None) handles backward compatibility with old NDJSON entries. No additional retry logic is needed for the Some path.

Recommend closing as won't-fix — the theoretical risk doesn't justify the added complexity.