"Ctrl++" and "Ctrl+," silently parse as plain "Ctrl", so the + and , keys cannot be bound #108

What's wrong

Chord.Parse splits on '+' with StringSplitOptions.RemoveEmptyEntries:

string[] parts = [.. value.Split('+', StringSplitOptions.RemoveEmptyEntries).Select(p => p.Trim())];

For "Ctrl++", the token for the plus key is empty and gets dropped, leaving just Ctrl. Phrase.Parse does the same with ',', and KeybindingService.ParseChord / ParsePhrase have the same behaviour.

Reproduction (verified against current main)

Chord.Parse("Ctrl++").ToString();             // "Ctrl"
Chord.Parse("Ctrl++") == Chord.Parse("Ctrl"); // true
Phrase.Parse("Ctrl+,").ToString();            // "Ctrl"

No exception is thrown.

Why it matters

"Ctrl++" (zoom in) and "Ctrl+," (settings) are among the most common shortcuts in desktop apps. Binding either one silently binds a lone Ctrl modifier instead. That binding then either never fires or fires whenever Ctrl is pressed, and it conflicts with every other bare-Ctrl binding.

Suggested fix

Do one of the following:

• Tokenize so that an empty segment after a separator is the literal key. For example, "Ctrl++" becomes [Ctrl, +], and a trailing "," in a phrase becomes the comma key.
• Require named keys (Plus, Comma), document them, and throw on empty segments rather than dropping them.

Either way, input that parses to fewer keys than the user typed should never succeed silently.

Acceptance criteria:

• Chord.Parse("Ctrl++") is not equal to Chord.Parse("Ctrl").
• It either represents Ctrl+Plus or throws FormatException / ArgumentException.
• The same holds for Phrase.Parse with a comma key.