Describe the issue
My motivation:
While working on #5637 I figured that prune is not secure enough for our use cases. Our git client is used by game developers, so the LFS cache is (force) pruned very regularly to significantly reduce the size of the project folder. This is necessary for git (LFS) to be a valid competitor to e.g. perforce.
The one thing that version control must prevent is data loss, and git LFS prune may be very destructive as it does not take the reflog or indexed files into account, for example. Beside #5637, there is also this open issue #4593.

My proposal:
In this commit Anchorpoint-Software@749af8b I've added a --safe option to LFS prune that only prunes objects that are 100% on the remote server. So in contrast to --verify-remote, --safe does not exit if a file is not available on the remote and orphan commits and indexed files are not pruned.

I am curious to hear what you think about this?