Protect unrelated and active result folders from QuPath retention cleanup #14

Failure mechanism

LcDialog.newJobDir in LabConstrictorTools.groovy writes into the shared <LC_HOME>/results folder, then recursively deletes every subdirectory beyond the most recent RESULTS_KEPT, selected by alphabetical name:

(root.listFiles({ File f -> f.isDirectory() } as FileFilter) ?: [])
    .sort { it.name }.reverse().drop(LcConst.RESULTS_KEPT)
    .each { it.deleteDir() }

There is no check that an entry belongs to LabConstrictor, was produced by QuPath, or has finished running. This is broader than the already unsafe CLI cleanup. Multiple hosts share this directory.

Impact

• A researcher-created backup directory under <LC_HOME>/results can be removed when enough QuPath jobs run.
• A directory containing a still-running Toolkit, Fiji, Napari or QuPath job can be removed by a new QuPath run.
• Deletion happens automatically, without an explicit cleanup command or user confirmation.

Related cross-host issues: Toolkit #55 and Fiji #28. Fix retention consistently, rather than treating each host's directory names as its exclusive property.

Acceptance criteria

• Only verifiably owned, completed result folders are eligible for deletion.
• Foreign folders and active jobs survive cleanup, including with more than RESULTS_KEPT concurrent jobs.
• Arbitrary user folders are not removed; symlink behavior is explicitly tested so cleanup cannot traverse outside the retention directory.
• Tests use a temporary LC_HOME with files whose contents must survive; a multi-process integration test verifies cross-host behavior.

Severity: P1 — potential irreversible loss of analysis files. Source-traced; no destructive tests run against user data.