D3c: -R URL forms + .git stripping + :443 normalization (C16+C17+C24)

[espadonne]

Summary

Three MED findings from the C-audit, all about gh-compat parsing leniency on user-supplied repo + hostname strings. Cohesive surface (one parser + one normalizer); independent tests.

• C16 — -R "https://shithub.sh/owner/repo" and -R "git@shithub.sh:owner/repo.git" were rejected with "repo: expected owner/name". gh accepts both. Now: ParseRepoArg routes URL-shaped inputs through internal/git.ParseRemoteURL (which already handles HTTPS, HTTP, SSH, and the SCP-like git@ form).
• C17 — -R "owner/repo.git" (trailing .git from git remote get-url) wasn't stripped and produced a 404 against /repos/owner/repo.git. Now trimmed.
• C24 — --hostname "shithub.sh:443" errored "no token configured" instead of finding the configured shithub.sh entry. NormalizeHost now strips the default HTTPS port (:443) but leaves non-default ports intact.

Test plan

• TestParseRepoArg extended with 6 new cases: HTTPS+.git, HTTPS bare, SSH .git, SSH bare, bare .git, host-prefixed .git.
• Defensive case: https://shithub.sh/onlyowner (no repo segment) still errors.
• TestNormalizeHost extended with 3 cases for :443 stripping (bare, HTTPS-prefixed, mixed-case).
• All existing TestNormalizeHostRejectsMalformed cases still reject (no :443 strip-then-accept on malformed inputs).
• make ci green locally.

Notes

The URL-detection heuristic (isLikelyURL) is conservative — it only flips to the URL parser when the input contains :// or the SCP-like user@host: form. Bare owner/repo strings with no special chars stay on the existing path so the change is purely additive.