fix: atomic file publication and authenticated IPC lock daemon

[gnodet]

Summary

Fixes 3 findings from the maven-resolver security audit (scan-maven-resolver-20260811):

Finding	Severity	Description
f007	MEDIUM	Windows final move is truncate-and-copy, not atomic; truncated artifact can survive as trusted
f020	LOW	IPC lock daemon protocol is unauthenticated; bootstrap secret leaks via argv
f025	LOW	IPC lock key digest concatenates names without separators

Root cause: The concurrency layer has spots where its own guarantee is violated: Windows publication is not atomic, and the IPC lock daemon trusts every connection and digests keys ambiguously.

Fix: Atomic rename on Windows with retry, authenticated IPC daemon with SecureRandom tokens and peer credentials, unambiguous length-prefixed key digest.

Test plan

• Existing tests pass
• Windows atomic move tested
• IPC daemon authentication tested
• Key digest uniqueness tested

🤖 Generated with Claude Code

[gnodet]

Excellent security-hardening PR — defense-in-depth across the IPC lock protocol with comprehensive tests.

Strengths

• Bootstrap token via stdin instead of argv prevents exposure through /proc/<pid>/cmdline — the right approach
• SecureRandom over Random for the bootstrap token — required for a security credential
• Per-connection context scoping is a solid privilege-separation fix: one client can no longer close or acquire on another client's lock contexts
• Netstring-like lock key digest prevents boundary-shifted collisions (["foo","bar"] vs ["foob","ar"]) — clean and correct
• Bounded preallocation (Math.min(sz, 1024)) prevents memory exhaustion from malicious wire-supplied sizes
• Socket file permissions (owner-only rwx) on Unix domain sockets add a second layer beyond the token
• retryingMove never-truncate contract eliminates the torn-read window where a concurrent reader or process kill could observe a truncated file at the final path after checksum validation
• Test coverage is thorough: IpcServerAccessControlTest validates context isolation and token enforcement, IpcNamedLockFactoryTest covers digest collision resistance, PathProcessorSupportTest covers retry, never-truncate guarantee, and staging fallback

One observation

@since 2.0.22 tags — Same question as the sibling PRs in this security audit batch (#2079–#2086): the maven-resolver-2.0.22 tag already exists in the repository, so these new API additions (IpcServer(SocketFamily, String) constructor at line 232, restrictToOwner in SocketFamily) should use @since 2.0.23 (or whatever the next release version will be).

Overall this is high-quality, well-thought-out security work. Well done!