Persistent-ref lock files accumulate one per checkpoint and nothing reaps them

Follow-up to #1926 (merged as c7a96436).

persistentRefLockPath creates a lock file per ref under <git-common-dir>/entire-persistent-ref-locks/ (cmd/entire/cli/checkpoint/persistent_ref_update.go:63). Under the git-refs backend that is one file per checkpoint ref, created on first write and never removed. The MigrateBranchToRefs path creates one for every migrated checkpoint in a single pass.

cmd/entire/cli/strategy/cleanup.go has no reference to that directory, so entire clean does not discover or reclaim it.

Why this is worse than the existing precedent

shadow_ref.go:80-84 uses the same pattern for <git-common-dir>/entire-shadow-locks/, and cleanup.go doesn't know about that one either. The difference is bound: shadow lock files are keyed by base commit and worktree, so the set is bounded by branch activity. Persistent-ref locks are keyed by checkpoint ref, so the set grows monotonically with checkpoint count and never shrinks.

Suggested fix

Add both lock directories to cleanup discovery. A lock file is safe to remove when no process holds it, which flock makes cheap to test - try to acquire non-blocking, and delete on success. Reaping both together also closes the pre-existing shadow-locks gap.

Start with cmd/entire/cli/strategy/cleanup.go and inspect persistent_ref_update.go:63 and shadow_ref.go:80-84 to understand the two lock directories. Verify that cleanup discovers both directories, removes only files whose locks can be acquired non-blocking, and leaves held lock files in place.