Fetch a crate from any forge, not only github

[jackmarsh]

Closes #21.

Where we already were

rust_repo covers both sources in one rule, which is the go_repo shape:

if git_repo:       download = rust_git_download(...)     # a forge
elif not download: download = rust_crate_download(...)   # crates.io

So the gap was never the declaration shape, only which forges the fetch understood.

What was wrong

The archive URL was https://{host}/{repo}/archive/{rev}.tar.gz with host defaulting to github, and rust_repo never passed host at all. The docstring claimed "github.com, gitlab works too". That was never true, checked rather than assumed:

forge	scheme
github.com	/archive/<rev>.tar.gz	200
codeberg (gitea/forgejo)	/archive/<rev>.tar.gz	200
git.sr.ht	/archive/<rev>.tar.gz	200
gitlab.com	/-/archive/<rev>/<proj>-<rev>.tar.gz	200
gitlab.com	/archive/<rev>.tar.gz	403

A gitlab repo declared as though it were github failed at download with nothing to say why.

sync --import was worse than silent: it warned and skipped, telling the reader to write a download= rule by hand.

The change

git_repo takes a full URL as well as the owner/repo shorthand, and the archive URL is built per forge scheme. The host picks the scheme, which cannot work for gitlab running somewhere its name does not say, so git_forge = "gitlab" says it outright.

sync --import records any other forge as the URL it was cloned from.

No git. This is remote_file and a URL, as it was before, so there is no host tooling and no new hermeticity question. A forge serving neither scheme still needs download=, which is the same escape hatch go-rules offers.

Why we cannot do what the neighbours do

Worth recording, since it came up: both neighbours delegate forge support to the language toolchain.

• go-rules shells out to go mod download, which resolves any module path through the Go module proxy. It never sees a forge, a URL or a git command.
• rules_rust shells out to cargo: cargo update, cargo fetch, cargo generate-lockfile, cargo vendor.

Neither is available here. Cargo is ruled out, and unlike Go's toolchain it has no standalone "fetch this repo at this revision" command anyway. So this is ours to build, and the per-forge table is the cost of not invoking cargo.

Testing

test/forge asserts the URLs while the package is parsed, so a change to the scheme fails the build rather than a fetch, and no network is involved.

It caught the first version of this change: split(sep, 1) does not take a maxsplit in this dialect, so every URL input raised index out of range. Every URL form was broken and the unit test found it before anything was pushed.

Covered: the shorthand, a github URL, a .git suffix as a Cargo.lock spells it, a gitlab group path (the tarball is named for the project, not the path), an explicit git_forge override, and the same host without one.

The --import half has a test asserting a git+https://gitlab.example.com/x/y#deadbeef source now round-trips instead of being skipped. That fixture already existed, asserting it was skipped.

189 tests pass, clippy clean, fmt clean.

Not covered

No CI step fetches from a real non-github forge, because no rule here fetches over the network in CI. The URLs are verified by hand against live forges (table above) and asserted at parse time. Next step is a real declaration in rust-corpus.