Support non-ASCII branch names during workspace cloning

What does this MR do and why?

When creating a workspace from a branch containing non-ASCII characters (for example, feature/günter-überarbeitung or CJK/Cyrillic refs), workspace cloning fails with exit code 128 because Ruby's Shellwords.shellescape prepends backslashes to non-ASCII UTF-8 bytes before passing --branch into INTERNAL_POSTSTART_COMMAND_CLONE_PROJECT_SCRIPT.

InternalPoststartCommandsInserter.shellescape_ref mirrors Ruby stdlib Shellwords.shellescape (escaping all ASCII shell metacharacters, whitespace, and newlines and rejecting NUL bytes) while adding [:^ascii:] to the negated character class so valid UTF-8 non-ASCII branch characters pass through unescaped to git clone --branch.

References

• Closes #596326
• Related to #547719 (closed)

Screenshots or screen recordings

N/A — backend bug fix for workspace poststart clone command generation.

How to set up and validate locally

1. In a local GitLab GDK environment configured with Workspaces (Remote Development), open a project and create a branch whose name contains non-ASCII UTF-8 characters (for example feature/günter-überarbeitung or ветка/тест-機能).
2. Create a new workspace targeting that non-ASCII branch.
3. Wait for the workspace poststart setup to complete and open the workspace terminal.
4. Confirm the repository cloned cleanly onto the non-ASCII branch without git clone --branch failing with exit code 128.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.