Share the git URL check, and refuse the transports Omarchy does not clone from (backport of #8174)

Backport of the shared URL check (PR #8174, merged to quattro as 68ab12f7) onto
the v4-0-1 release branch, on top of the #8067 backport it follows.

omarchy-theme-install and omarchy-plugin-add both clone a URL a stranger can
choose, and each carried its own copy of the rule that refuses a git option or a
transport helper before cloning. The rule now lives in omarchy-git-url-check and
both callers ask it: two copies of a security check drift, and the second copy
arrived four months after the first only because someone went looking for it.

That rule was also enforcing half of what it described. <helper>::<address> is
one of two shapes git resolves a remote helper from -- it also runs
git-remote-<scheme> for <scheme>://<address> whenever the scheme is not one it
connects itself, so ext::sh -c id and ext://sh -c id reach the same helper while
only the first was refused. Nothing exploitable follows on a stock system:
protocol.ext.allow defaults to never, and the :// spelling hands git-remote-ext
a command name it cannot exec. But a third-party helper installed on PATH is
reachable through the scheme form alone, and a guard is worth more when it
enforces the rule it states.

The :// shape cannot be refused the way :: is, because it is also how every
legitimate URL arrives, so the scheme is checked against the transports git
still connects itself: ssh git git+ssh ssh+git http https ftp ftps file.
git+ssh and ssh+git are on that list because they are spelled like a helper and
read as plain ssh; leaving them off would refuse a URL that clones today. ext
and fd are off it deliberately. A single colon is always scp-style ssh and a
bare path is always a path, so neither needs constraining.

The check fails closed: the callers read a non-zero status as a refusal, so a
missing omarchy-git-url-check refuses the URL rather than waving it through.

Clean cherry-pick on top of the #8067 backport: every file is byte-identical to
quattro, so merging v4-0-1 into quattro resolves without a conflict. test/shell
passes: 189 files, including the one this adds. test/cli passes, so the new
command's metadata is well-formed. Exercised the check here: https, scp-style,
ssh, git+ssh and scp-style IPv6 all pass, while ext:: ext:// fd:: fd:// and a
leading-dash form are refused, as is an uppercase EXT:// spelling.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018DEMYa9UWtroz93DhMTtcV

test/shell.d/plugin-add-test.sh

@@ -111,6 +111,20 @@ for bad in "ext::sh -c touch /tmp/omarchy-guard-test" "fd::17"; do
 done
 pass "plugin add rejects transport-helper URLs before cloning"
 
+# The `://` spelling of the same thing: git resolves git-remote-<scheme> for any
+# scheme it does not implement itself, so `ext::` and `ext://` reach the same
+# helper and both have to be refused.
+for bad in "ext://sh -c id" "gcrypt://example.com/x"; do
+  rm -f "$clone_marker"
+  output=$(add_url "$bad") &&
+    fail "plugin add rejects a transport-scheme URL: $bad" "$output"
+  grep -qF "which Omarchy does not clone from" <<<"$output" ||
+    fail "plugin add names the transport-scheme rejection: $bad" "$output"
+  [[ ! -e $clone_marker ]] ||
+    fail "plugin add reached git clone for a transport-scheme URL: $bad"
+done
+pass "plugin add rejects transport-scheme URLs before cloning"
+
 # Option-shaped URLs on argv are refused before clone — by the option parser
 # (`-*` falls to "unknown add option"), not the guard. The guard's own
 # leading-dash arm is only reachable through the interactive gum prompt and is