Pointing -p at a bare git repository (repo.git, ~/.cfg) or inside .git still offers branch refs for deletion: #205 skips VCS directories only below the root #207

What happens

#192/#198 (fixed by #194/#205) stop the scan from walking into .git, .svn, .hg, .bzr, CVS, _darcs and bare git repositories. Those checks run only in ShouldRecursePredicate (FileDeduplicator/FileScanner.cs:128-129), which is evaluated for subdirectories. Nothing checks the root itself or its ancestors.

Repro, run against main @ 9805334: the root is a bare repository with HEAD, objects/, and refs/heads/main and refs/heads/feature-long pointing at the same commit hash.

• Observed: Scan returns one duplicate group, and DryRun/Deduplicate would delete refs/heads/feature-long, which deletes the branch.
• Expected: the verb refuses the root (or skips it with a clear message) when it is a VCS metadata directory or lies inside one.

The same applies to -p proj/.git, -p proj/.git/refs and -p ~/.cfg, the dotfiles bare-repo pattern #198 named. Any of these is a plausible target when someone points the tool at "the folder with all my config" or at a mirror directory.

Why it matters

The fix for #198 exists because deleting a ref file silently removes a branch, and loose objects are also byte-identical across packs. Running at the repository instead of above it hits the same data loss. The README describes skipping VCS directories "under the root", but nothing documents a VCS root as intentionally allowed.

Suggested fix

In IsScannableDirectory (or BaseVerb.Run), refuse a root when it or any ancestor:

• has a name in VersionControlDirectories, or
• passes IsGitDirectory.

Report the refusal and return a non-zero exit, the way a missing directory is handled since #144.

Acceptance criteria

• Scan, DryRun, Stats and Deduplicate on a bare-repo root, on .git, and on a folder inside .git report the refusal and delete nothing.
• A normal working tree that contains .git behaves as today.