Harden deletion logic and cache cleanup safety

[c0rychu]

Current removal path is brittle: rm_rf raises if the target is already gone and link calls it on venv.parent without verifying what it will delete. There are no guards to ensure the path is actually a uvlink cache directory or that a symlink points to the expected target. Proposal: make removal idempotent (gracefully skip missing paths), add guardrails (only remove paths under the chosen cache root or matching metadata), and cover these cases with tests so concurrent/manual cleanup cannot trigger unexpected exceptions or deletions.

[c0rychu]

Feedback from a friend:

• Case 1, the simplest one I think: the target (by default ".venv") is a directory (e.g. a previously created env). The strategy in this case could be, instead of rm_rf'ing it, to move it's contents to uvlink cache and symlink it. This would also allow you implement, perhaps a less frequtly used but a useful recovery command "uvlink unlink" that'd move a cached dir back into the project.

• Case 2: a preexisting uvlink cache, when trying to run "uvlink link" again for the same target.

  • Case 2a: the target is still linked - there's a symlink that points to the matching cache. In this case, maybe no action is a better option unless a special flag as in "--force-recreate" is passed.
  • Case 2b: the cache exists but the symlink is missing. The suggested default in this case could be to relink to an existing cache. And a non-default option could be to gc the old cache (though, I still do not like the idea of a too easy rm_rf, even with a user prompt) and create a new cache dir. Maybe you can think of additional, less brutal options.
  • Case 2c, where "c," conveniently stands for "conflict." The matching cache dir already exists but there's also a local dir under the target ENV name. One of them has to go to proceed. My intuition would be for a tool like uvlink to fail with no action by default. It could print a guidance to the user on paths to resolve the conflict:
    • 1. the user can execute "uvlink gc" this would convert the situation into "case 1"
    • 2. the user can move/delete their local env dir, which would convert this into "case 2b"

• Case 3: the target is already a symlink but one that doesn't point to the matching uvlink cache dir. No rm_rf is necessary since deleting the symlink does not delete any data. So, the default action could be to just remove the ols symlink and do what "uvlink link" does normally.

Also, since cache dir names are deterministic + you have metadata in project.json, you can detect if the symlink is pointing to non-matching previous uvlink cache. If the original location of that project doesn't exist anymore, it would be a reasonable assumption that project got moved/renamed, and suggest renaming the cache dir to match the hash (ie fix the link).

With all the suggestions above uvlink would only do rm_rf on the cached dirs, and never in the project dir. Because even in case 2c, the user would have to manually type "rm - rf not_important" if they actually want to delete a local dir.