Refuse a conf write that widens a path to its own ancestor

Several scripts delete inside a conf path — the orphan cleaner runs rm -rf under a download dir
and rsync runs --delete against a destination — so /mnt/user/Movies becoming /mnt/user is the
edit that turns a cleanup into a sweep. Depth cannot be the test, because /tv and /movies are
real container-internal values here; direction can. Clearing a path, making it relative and
'..' segments go with it, and autofix additionally requires a proposed path to exist, since
every probe it has is a network probe and proves nothing about a directory. Refusals now reach
the caller: a save whose only change was refused answered ok with no explanation.

Plugin/unraid/include/ai_repair.php

@@ -139,6 +139,20 @@ function vv_ai_finding_may_autofix(array $f): bool {
     if (empty($f['proven']))                        return false;
     if (($f['proposed'] ?? null) === null)          return false;
     if (vv_ai_conf_is_toggle((string)($f['conf_key'] ?? ''))) return false;
+
+    // A third condition, for paths only. "Proven" means a probe answered, and every probe this
+    // has is a network probe — nothing in it can answer a filesystem question, so a path
+    // proposal reaches here carrying a proof that is about something else entirely. Requiring
+    // the directory to exist is the equivalent evidence, and it is the difference between
+    // pointing a cleanup at a real share and pointing it at a typo that will be created empty
+    // by the first script to write there.
+    //
+    // vv_conf_path_write_ok() still runs inside the writer underneath this. That one refuses
+    // what is dangerous; this one refuses what is merely unproven, which is a bar only the
+    // unattended path has to clear.
+    $proposed = (string)$f['proposed'];
+    if ($proposed !== '' && $proposed[0] === '/' && !file_exists($proposed)) return false;
+
     return true;
 }