Validate git host by exact match and sanitize cache path segments

Summary

Two security-hardening fixes in the source-fetching path.

1. Match git hosts by exact host, not substring

is_git_repo_url and authenticated_clone_url decided whether a URL belonged to github.com / gitlab.com / bitbucket.org using url.contains("github.com"). The URL comes from package metadata (repository.url, project_urls, homepage), so a look-alike host such as https://github.com.example.com/owner/repo passes the substring test. In authenticated_clone_url that means a configured GITHUB_TOKEN / GITLAB_TOKEN / BITBUCKET_TOKEN is rewritten into the clone URL and sent to the look-alike host as HTTP basic-auth.

This change parses the URL and compares host_str() for exact equality before treating a URL as a supported git host or embedding a token. A new supported_git_host() helper centralises the check so the selection gate and the token-injection point can't drift apart. The existing replacen is now safe because it only runs once the host is known to equal the constant.

2. Sanitise cache path segments

get_repo_path joined display_name and version/git-ref (both derived from untrusted input — package metadata, and the spec after @/#) under ~/.opensrc/repos with no validation. A ref such as vercel/next.js@../../../tmp/x therefore resolved outside the cache directory, and the same unsanitised path later feeds remove/clean.

A new ensure_safe_path_segment() rejects empty, ., .., and absolute components, while still allowing legitimate slash-bearing branch refs (e.g. release/1.0), which stay nested inside the cache.

Tests

Added regression tests for both issues:

• registries/mod.rs: substring-host rejected; token not embedded for a look-alike host; token still embedded for an exact host.
• cache.rs: traversal rejected in both ref and display name; absolute segment rejected; legitimate slashed branch ref allowed.

The full suite passes locally (cargo test), and the happy path is unchanged (e.g. fetch zod, fetch crates:serde still work).

Compatibility

No behavioural change for legitimate github.com / gitlab.com / bitbucket.org URLs or normal version/branch refs.