fix(git): reject tabs in ref names, git refuses them too

[BryanFRD]

Closes #798.

Two parts of that issue's analysis are wrong, and the fix here is smaller than what it proposed. Checked both before writing any code.

parse_ls_remote_tags is not broken. split_once('\t') keeps everything after the first tab, so a hypothetical sha<TAB>refs/tags/foo<TAB>bar line yields refname = "refs/tags/foo\tbar" and strip_prefix("refs/tags/") then gives "foo\tbar", which is correct. No parser change is needed.

The scenario is unreachable anyway, because git rejects tabs in ref names. A tab is an ASCII control character and check-ref-format refuses it:

$ git check-ref-format $'refs/tags/foo\tbar'; echo $?
1
$ git tag $'foo\tbar'
fatal: 'foo	bar' is not a valid tag name.

So the real defect is only in the validator. ensure_safe_refname_fragment carved tabs out of its control-character check on the premise that "tabs are technically allowed in refs", which is not true. The effect was that a tab in a tagTemplate got past our own check and failed later as an opaque fatal: '...' is not a valid tag name from a git subprocess, instead of the validator's actionable message.

Removing the carve-out collapses the whole condition to ch.is_control(), since \0, \n, \r and \x7f are all in Unicode category Cc and were already listed individually.

Verification

rejects_tab and every_rejected_control_char_is_one_git_also_refuses both fail against the previous condition:

test git::validate::tests::rejects_tab ... FAILED
test git::validate::tests::every_rejected_control_char_is_one_git_also_refuses ... FAILED

The second test is the one that matters: for each character the validator rejects it shells out to git check-ref-format and asserts git refuses it too, so the validator can never drift into rejecting a name git would have accepted. \0 is excluded from that loop because an interior NUL cannot be passed through argv at all; rejects_null_byte still covers it on our side.

---

Second layer of a stack of four. Based on #1052, and #1054 sits on top.

[ferrfleet]

Change is correct. The carve-out removal is a strict narrowing over what git itself accepts, and all four call sites (create_tag, create_or_move_tag, remote name and branch name in push.rs) are real refnames, so nothing legitimate loses. The old condition already contained ch.is_control(), so collapsing to it is behaviour-preserving apart from the tab.

One nit inline on the new test's name.

[github-actions]

SonarQube — aucune nouvelle issue

_{Comparaison entre le projet bac à sable de cette PR et la branche par défaut : SonarQube Community n'analyse pas les PR, ce delta est calculé côté CI. Détail}

[BryanFRD]

Renamed in 298051e to every_rejected_ascii_control_char_is_one_git_also_refuses.

Verified the premise rather than taking it on trust, and it holds. git accepts a C1 byte in a refname and rejects an ASCII one:

$ git check-ref-format "refs/tags/foo$(printf '\xc2\x85')bar"   # U+0085
ACCEPTED
$ git check-ref-format "refs/tags/foo$(printf '\x05')bar"
REJECTED

So the validator is deliberately stricter than git across the C1 range, which the existing doc comment already allows for ("not the full check-ref-format algorithm"). Only the test name was overclaiming, and the loop itself was always ASCII-only.