Branch patterns ? and [...] disagree with git branch --list on non-ASCII names: origin/? matches origin/é here but not in git #115

What's wrong

The README says branch patterns mean what they mean to git branch --list. But BranchPattern (MatchesOne / TryWalkBracket in Refs/BranchPattern.cs) matches on UTF-16 chars, while git's wildmatch matches on bytes. Any branch name outside ASCII therefore gets a different answer.

Observed differences

I compared BranchPattern with git branch -r --list over 43 patterns and 37 real refs:

Every ASCII-only pattern agreed.

Why it matters

A client that tests a pattern with git branch --list and then sends it here gets a different branch set. Its /state answer quietly leaves out branches it expected, or includes branches it didn't. This affects any team whose branch names contain accented letters or emoji.

Suggested fix

Match against the UTF-8 bytes of the pattern and the ref name, the way git's wildmatch does. That gives exact parity, including git's own byte-level behaviour for ? on multi-byte characters.

If byte-level ? is judged too surprising to copy, the README should instead state the deviation explicitly (code-point matching). As it stands, the README promises parity and the code doesn't deliver it.

Acceptance criteria

• A parity test runs the cases above (and the existing ASCII cases) through both BranchPattern and git branch --list against the same refs, and they agree.
• Branch patterns with [...] character classes match no branches, though git's branch --list honours them #43 / Branch patterns with POSIX character classes like [[:digit:]] silently match the wrong branches #56 behaviour for bracket and POSIX classes is unchanged.