fix(server): lock memory without IPC_LOCK

[julian-corbet]

Summary

• always attempt mlockall when no process capabilities are present
• rely on RLIMIT_MEMLOCK when CAP_IPC_LOCK is unavailable
• retain CAP_IPC_LOCK only when it is already in the permitted set, avoiding an invalid capability elevation attempt
• preserve the existing success and failure logging around memory locking

CAP_IPC_LOCK bypasses RLIMIT_MEMLOCK, but it is not required when the process has a sufficient limit. Previously the no-capability path returned before mlockall. The partial-capability path could also fail before mlockall by trying to add CAP_IPC_LOCK when it was not permitted.

Tests

• cargo test -p oo7-daemon --bin oo7-daemon
• cargo check -p oo7-daemon --bin oo7-daemon
• cargo clippy -p oo7-daemon --bin oo7-daemon --tests -- -D warnings
• cargo fmt --check

[github-actions]

📊 Code Coverage Report

Metric	Value
Current PR Coverage	83.56%
Main Branch Coverage	83.62%
Coverage Change	📉 -0.06%

Coverage report generated by cargo-tarpaulin

[julian-corbet]

Runtime confirmation: I built the daemon from this commit and ran it as an ordinary user with an empty effective/permitted capability set and an unlimited RLIMIT_MEMLOCK. It logged Successfully locked all memory pages, and the live process then reported a non-zero VmLck in /proc/<pid>/status.

One integration verifier initially sampled VmLck too early: the systemd D-Bus unit was considered started about 30 ms before the process reached mlockall(). Polling the process postcondition confirmed the lock; this was a readiness race in the verifier, not a failure of this patch.