Git: getRemoteRefs returns remote head refs with name and commit swapped

### Bug description

`Git.getRemoteRefs()` (extensions/git/src/git.ts) parses `git ls-remote` output and builds `Ref` objects. For remote **heads** the mapping is inverted:

```ts
if (match = /^([0-9a-f]{40})\trefs\/heads\/([^ ]+)$/.exec(line)) {
return { name: match[1], commit: match[2], type: RefType.Head };
}
```

Group 1 of that regex is the 40 character SHA and group 2 is the branch name, so every returned head has the SHA in `name` and the branch name in `commit`. The tags branch three lines below does it the right way round (`name: match[2], commit: match[1]`), which confirms the intent.

Example: for the line

```
52c293a05038d865604c2284aa8698bd087915a1 refs/heads/main
```

the function returns `{ name: '52c293a05038d865604c2284aa8698bd087915a1', commit: 'refs/heads/main' }` where it should return `{ name: 'main', commit: '52c293a05038d865604c2284aa8698bd087915a1' }`.

The only in-repo caller currently passes `{ tags: true }`, so the broken heads path is dormant today, but the method is part of the extension's repository surface and any use of `getRemoteRefs(remote, { heads: true })` gets unusable data.

### Steps to reproduce

1. Call `repository.getRemoteRefs('', { heads: true })` against any remote with at least one branch.
2. Inspect the returned array: `name` holds SHAs, `commit` holds ref names like `refs/heads/main`.

### Expected behavior

Head entries follow the documented `Ref` shape: `name` is the branch name, `commit` is the SHA, matching what the same function already produces for tags.

### Version tested

Commit `77f86f3d3a0` on `main`. Found by reading the parser and pinned with a unit test (`parseLsRemote`) that exercises real `ls-remote` output format; a fix is ready including regression tests for heads, tags, mixed input and multiple heads.