Bump go-git to v6 Beta

I've moved go-git and go-billy to v6.0.0-beta.1 and updated the other dependencies. Go itself can't be updated: 1.27.3 is already the latest release, so the toolchain pin is unchanged. The code builds, go test -race ./... passes, and golangci-lint reports 0 issues. I didn't run govulncheck because it isn't installed here. Nothing is committed.

Dependency bumps:

• Direct: go-git and go-billy alpha → beta.1, testify 1.11.1 → 1.12.1.
• Indirect: x/net 0.62.0, x/sync 0.24.0, ProtonMail/go-crypto 1.5.2, circl 1.6.5, sha1cd 0.7.0, go-winio 0.6.4, pflag 1.0.10.
• Cleanup: go mod tidy removed a few indirect entries that are no longer needed.

One behavior change from go-git beta.1. TestPartitionRefNamesRejectsDangerousNames/leading_dash_on_a_branch failed after the bump. go-git's ref-name check now accepts names that start with a dash, like refs/heads/-oProxyCommand=id. Upstream made this change on purpose to match git, which only blocks a leading dash when you create a branch or tag; git fetch and git clone copy such refs without complaint.

I followed upstream instead of adding our own dash check, for two reasons:

• It's what the code says it should do. The comment in internal/gitproto/refnames.go says git-sync uses go-git's check so that "nothing git considers legitimate is skipped".
• No command-injection path. The only place a ref name reaches a command line is the git tag -s converted/<name> refs/heads/<name> call in sha256convert, and neither of those arguments can start with -.

So refs like refs/heads/-foo are now mirrored instead of skipped. I updated the doc comment and moved that test case into the "keeps legitimate names" test. If you'd rather keep rejecting these names as extra hardening, it's a two-line check in PartitionRefNames.

I also added a "Changed" entry under Unreleased in CHANGELOG.md covering the bumps and the leading-dash change.

We never decided to reject them. The rejection came along with go-git's validator, which happened to include that rule at the time.

The rule was added in 0f6a015e ("Validate ref names arriving from a remote"). That commit was written against two specific threats:

1. Path traversal in convert-sha256. A name like refs/heads/../../config gets written through the repository filesystem and can overwrite config, HEAD or packed-refs.
2. Capability injection into receive-pack. A name containing NUL lets the source slip extra capabilities into the push git-sync sends to the target.

Neither threat involves a leading dash. To defend against them, the commit used go-git's ReferenceName.Validate instead of writing its own check, so that git-sync's idea of a valid ref would match git's. In alpha.5, Validate also rejected a leading dash on branches and tags, so the commit listed it among the rules it was picking up.

That list was slightly wrong. It describes the whole set as git's check_refname_format, but git doesn't apply the dash rule there. It applies it only when you create a branch or tag (check_branch_ref / check_tag_ref). go-git beta.1 fixed exactly that mismatch.

The test case's label, "argument-injection shape", reads like a reason. But it describes what the name looks like, not a path in git-sync where it could be exploited. As I checked earlier, no ref name lands in an argument position where git would read it as an option.

Dropping the rejection is in line with what the commit was trying to do: match git, block traversal and NUL, and skip nothing git accepts. There's one more effect to know about. --map values go through the same Validate call in internal/validation/validation.go:219, so a mapping like refs/heads/-foo is now accepted at startup instead of rejected. That's consistent with the rest, and no test covered it either way.