Workspace branch name (pr-N) doesn't match the actual PR branch (issue-N-hash), causing pushes and session-backup to target the wrong PR

[skulidropek]

Problem

When a workspace is created to work on a PR, it checks out a branch named `pr-{N}` (e.g. `pr-387`).
But the PR on GitHub was opened from a branch named `issue-{issue}-{hash}` (e.g. `issue-383-173b143467d9`).

These are two different branches — so every git push and every session-backup comment lands on the wrong PR.

How it manifests

Observed in PR #387 / issue #383:

What happened	Expected
Local branch: `pr-387`	Should be: `issue-383-173b143467d9`
`git push origin pr-387` → updates PR #399 (auto-created for `pr-387`)	Should update PR #387
Session-backup comments posted to PR #399	Should be posted to PR #387
`gh pr merge 387` works, but agent never pushes to the right branch by default	Agent should push to the PR's actual head branch
Merging `main` into workspace required manual `git push origin pr-387:issue-383-173b143467d9`	Should happen transparently

Root cause

In `packages/docker-git-session-sync/src/backup.ts`, `getPrNumberFromWorkspaceBranch` only recognises branches matching `pr-refs-pull-{N}-head`:

```typescript
const getPrNumberFromWorkspaceBranch = (branch: string): number | null => {
const match = branch.match(/^pr-refs-pull-([0-9]+)-head$/u) // ← never matches "pr-387"
...
}
```

And `findPrContext` falls back to `gh pr list --head pr-387`, which finds PR #399 (the auto-created PR for the `pr-387` branch) — not the intended PR #387.

The workspace provisioning creates branch `pr-387` instead of checking out the existing PR branch `issue-383-173b143467d9`.

Suggested fix

When provisioning a workspace for PR #N:

1. Fetch the PR's actual head branch via `gh pr view N --json headRefName` and check it out instead of creating `pr-N`.
2. Or, store the target PR number in the workspace config (e.g. `.docker-git/workspace.json`) so the agent and session-backup can always resolve the correct PR regardless of local branch name.
3. Or, extend `getPrNumberFromWorkspaceBranch` to also match `pr-{N}` → treat it as PR number `N` (quick workaround, but doesn't fix the push-to-wrong-branch issue).

Option 1 is the cleanest: the local branch name matches what GitHub expects, and all tooling works without special-casing.

Frequency

This happens on every workspace that is created for an existing PR — the pattern is consistent across all recent PRs in this repo (all use `issue-{N}-{hash}` branch names, all workspaces land on `pr-{N}`).