fix(publish): sanitize server-controlled artifact path (GHSA-x55v-q459-68ch)

[proggeramlug]

Summary

Fixes the path-traversal / arbitrary-file-write reported in GHSA-x55v-q459-68ch.

perry publish processes ArtifactReady WebSocket messages from the build server and used the server-supplied artifact_name (and download_path) verbatim when building the local destination path. Since PathBuf::join does not normalize .. or reject absolute paths, a malicious/compromised hub could:

• Arbitrary write (Path A & B destination): deliver artifact_name = "../../.ssh/authorized_keys" (or an absolute path) and have downloaded content written anywhere the process can write.
• Arbitrary local read (Path B): in the self-hosted-hub local-copy path, set download_path to any local file (e.g. ~/.aws/credentials) and have it copied into the output directory.

The primary multi-victim vector is a malicious PR setting [publish] server = "https://attacker…" in a repo's perry.toml; CI runs (--no-interactive / non-TTY) get no confirmation prompt.

Fix

• sanitize_artifact_name() reduces the server-supplied name to a single, traversal-free file name (rejects empty, ., .., embedded / or \, absolute/drive-prefixed paths) before it's joined onto the output dir. This closes the arbitrary-write vector for both paths.
• server_is_local() gates the download_path local-copy shortcut to loopback hubs only (localhost, 127.0.0.0/8, ::1). A remote hub's local filesystem path is meaningless and is no longer honored — remote hubs fall back to the existing HTTP download. This closes the arbitrary local-file-read vector.

Tests

Added unit tests in commands/publish/tests.rs:

• accepted plain names (incl. whitespace trimming)
• a battery of traversal/absolute/separator payloads, all rejected
• the loopback gate (localhost/127.0.0.1/[::1] allowed; public hosts, private LAN IPs, and unparseable URLs rejected)

cargo test -p perry --bins publish::tests → 27 passed, 0 failed.

Notes

• No behavioral change for legitimate runs: artifact names are normally bare filenames, and the local-copy shortcut only applied to same-machine self-hosted hubs (still allowed via loopback). Remote self-hosted hubs that previously relied on a shared-filesystem download_path will transparently fall back to HTTP download.
• Heads-up: this PR references an advisory that is still in triage. If you'd prefer to land it privately first, it can instead go through the advisory's temporary private fork before publishing.