[Bug]: Redundant NSLocks in XPC Message and Server

[hluaguo]

I have done the following

• I have searched the existing issues

Steps to reproduce

1. Run any container CLI command (e.g. container run ... or container system start).
2. Every interaction with the daemon via ContainerXPC creates XPCMessage or XPCServer.
3. In XPCMessage.swift, XPCServer.swift, and ProgressUpdateClient.swift, NSLock instances wrap individual accessor and lifecycle calls.

Problem description

Every individual call to xpc_dictionary_get_* / xpc_dictionary_set_* is wrapped in an NSLock.withLock. However:

1. No multi-step atomic operations exist (each lock wraps exactly one accessor).
2. The XPC runtime already serializes connection activity. As stated in xpc_connection_create(3), every connection has an associated dispatch queue, and all activity (including event handler invocations) takes place on a distinct serial target queue.
3. Writes target message-local dictionaries that are thread-confined before transmission. Concurrent reads are safe.

This redundant synchronization incurs unnecessary lock/unlock CPU overhead (compare-and-swap and memory fencing instructions) for every single XPC interaction.

Environment

• OS: macOS 27.0 (Build 26A5368g)
• Xcode: 26.0.1 (Build 17A400)
• Container: 0.34.0

[hluaguo]

For reference, the macOS man page for xpc_connection_create(3) under the TARGET QUEUES section explicitly documents this serialization guarantee:

"Each connection has an associated target queue. All connection-related activity will happen on an internal queue which is synchronized with the target queue. Event handler invocations are included in connection-related activity."

By default, connections target a serial queue (DISPATCH_TARGET_QUEUE_DEFAULT), meaning all event delivery and lifecycle invocations (such as in XPCServer and ProgressUpdateClient) are serialized by the XPC runtime. This validates that user-space locks wrapping single accessor calls are redundant.