Stop cargo-clean racing its own deletions
-execdir removed target/ while find was still walking the tree, so find then tried to descend into directories it had already queued and that no longer existed -- the "No such file or directory" lines, one per project it had just cleaned successfully. Matching Cargo.toml files also meant descending into target/ itself and matching the vendored manifests under target/package, doing redundant work in the largest directories on disk. Match the artifact directories directly instead, confirm a sibling Cargo.toml, and -prune them so find never walks into anything it is about to delete. The "Operation not permitted" lines are just find hitting SIP- and TCC-protected paths when run from $HOME, so stderr is dropped. Those denials also make find exit 1, which meant every successful run from $HOME reported failure; hence the explicit exit 0, since the *-up scripts alongside this one chain on &&. The old last statement was `test -d coverage && rm -rf coverage`, so the exit status had been reporting whether the final project happened to have a coverage dir. Also takes optional paths instead of always assuming the cwd.