fix(compress): exclude ENOLCK from the unsupported-filesystem degrade, guard chmod

ENOLCK means the kernel is out of lock-record memory (transient), not "this
filesystem has no locking" — EOPNOTSUPP/ENOSYS are the real capability
signals. Treating ENOLCK as unsupported let a genuinely contended lock
proceed unlocked, reintroducing the interleaved-write race this PR exists to
prevent. Verified with a mocked ENOLCK against a real holder before the fix.

The new locks-dir chmod(0700) was unguarded and could hard-fail on the same
class of filesystem (CIFS/FAT/some FUSE mounts) the flock degrade was added
to tolerate; wrapped in contextlib.suppress(OSError) to match the other
best-effort guards in this function.

Also: reworded lock_path_for's docstring, which cited a name-leak rationale
two sibling fixes in this branch already made moot (sensitive files are
refused before the lock is ever taken, and the locks dir is now 0700); moved
a misplaced comment to sit above the checks it describes instead of above
the lock acquisition; and added test coverage for the degrade branch, the
ENOLCK exclusion, the chmod, and the no-lock-file-for-rejected-input case,
none of which the prior commits had tests for.