Fix wrong PR matched for worktree branches with cross-branch upstream

[Copilot]

PRs disappear from the panel when the workspace folder is a manually-created git worktree (e.g. git worktree add -b feature-foo <path> origin/develop). Repo discovery is actually fine — VS Code's git extension follows the .git pointer → commondir chain correctly — but two bugs in PR matching cause the active PR to resolve to the wrong (closed) PR and clear the panel.

getUpstreamUrlAndName uses upstream name as PR head ref

git worktree add -b feature-foo <path> origin/develop sets:

branch.feature-foo.remote = origin
branch.feature-foo.merge  = refs/heads/develop

So branch.upstream.name === "develop", and the extension was querying GitHub with headRefName: "develop" — matching an unrelated closed PR rather than the open PR for feature-foo. The fix prefers the local branch name when it differs from the tracked upstream, since that is what git push uses by default and what GitHub's headRefName will be:

const upstreamBranchName = (branch.name && branch.upstream.name !== branch.name)
    ? branch.name
    : branch.upstream.name;

getMatchingPullRequestMetadataForBranch sort order

The duplicate-entry handling added in #8063 used (a, b) => b.value < a.value ? 1 : -1, which sorts ascending, so it always returned the oldest PR association instead of the most recent. Lexicographic comparison of owner#name#5 vs owner#name#42 is also wrong across digit counts. Now parses the trailing PR number and sorts numerically descending.

Other

• Unit test in pullRequestGitHelper.test.ts covering the duplicate-config-entry case.
• Replaced two pre-existing em-dashes in vscode.proposed.chatSessionsProvider.d.ts with hyphens to unblock the hygiene pre-commit hook.