fix(storage): preserve private lock creation mode

[ScriptedAlchemy]

Summary

Follow-up to merged #395.

• create private-store sidecar lock files through the same owner-only open path as private data
• tighten an existing lock file to 0600 before entering the critical section
• retain the shared read/write lock primitive for Windows LockFileEx
• clarify that monitor mmap locking uses the data handle itself, not a sidecar

Root cause

#395 generalized lock opening through plain OpenOptions and chmodded a private lock only after a successful append/unlock. On a failed append, a newly created lock could remain at umask-default permissions; this regressed the previous atomic 0600 create behavior.

Tests

• new Unix private-lock creation regression: pass
• private concurrent append/reusable-lock/writable-file tests: 3 passed
• cargo clippy --workspace --all-targets --locked -- -D warnings: pass

[changeset-bot]

⚠️ No Changeset found

Latest commit: 0e1e8cb

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR