skillctl: Path traversal and symlink-follow in skillctl allow arbitrary file disclosure and deletion

Summary

## Impact

`skillctl` 0.1.0 and 0.1.1 contained four path-safety vulnerabilities that, in combination, allowed an attacker to:

1. **Exfiltrate arbitrary files on the operator's machine** by publishing a malicious skills library containing a symlink inside a skill folder (e.g. `niania → /home/user/.aws/credentials`). The symlink fell through `entry.file_type().is_dir()` in `fs_util::copy_dir_all`, was dereferenced by `fs::copy`, and the target's content was copied into the project. A subsequent `skillctl push` would have published the secret to the (possibly public) library — what the reporter called "round-trip path exfiltration".

2. **Delete arbitrary directories outside the project or library root** by crafting a `.skills.toml` with a malicious `destination` or `source_path` field. Both were deserialized as `PathBuf` with zero validation. Because `Path::join` lets an absolute right-hand side replace the base, `destination = "/home/user/.ssh"` made `cwd.join(...)` resolve outside the project; `..` traversal was equally unguarded. Downstream `remove_dir_all` in `replace_folder_contents` then wiped arbitrary writable directories on `skillctl pull` / `push` / `detect`. `.skills.toml` is the exact kind of file teams commit and exchange via PR; a single merged malicious PR was sufficient to weaponise the maintainer's next `skillctl pull --all`.

3. **`detect --target` accepted `..` traversal**, even though absolute paths were rejected. `--target ../../../etc` would have written outside the library root.

4. **Fork-name validation accepted `.` and `..` literally**, so a fork named `..` would have produced a `Path::join` resolving to the parent directory and `fs::rename` could have clobbered it.

## Patches

Fixed in [v0.1.2](https://github.com/umanio-agency/skillctl/releases/tag/v0.1.2):

- Symlinks inside skill folders are hard-rejected at copy time (both top-level source and any descendant entry). - `.skills.toml` `destination` and `source_path` are validated at load time and reject absolute paths, `..` components, and Windows-prefix components. - A new `path_safety::safe_join` helper is wired (defense-in-depth) at every destructive call site in `pull.rs` / `push.rs`. - `detect --target` and the interactive custom-path prompt go through the same `validate_relative_subpath` helper. - `validate_fork_name` explicitly rejects `.` and `..`.

Threat-model note: the fix is purely lexical (component-level) plus an explicit symlink check at copy time. No filesystem `canonicalize` calls were added, avoiding TOCTOU windows.

## Credit

Reported privately on 2026-05-19 by **firebaguette** via the Umanio Discord (the reporter declined GitHub credit, so this advisory carries no structured credits field).