fix: reply to unknown XPC routes and make request timeout cancellable

[radheradhe01]

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

Motivation and Context

Two related issues in the XPC request path:

1. Unknown route hangs the client. XPCServer dispatches with if let handler = routes[route] { ... } and no else. An unknown route produces no reply at all, so the client blocks until its timeout (or forever, if it sent none).
2. The client timeout is illusory. XPCClient.send races a timeout task against the reply task in a withThrowingTaskGroup. The reply task uses withCheckedThrowingContinuation, which is not cancellation-aware. When the timeout fires, the group tears down and awaits the reply task — which only completes when the daemon actually replies. Against a live-but-hung daemon the "timeout" never returns.

This change:

• XPCServer: adds the else branch and replies with an invalidArgument error for unknown routes.
• XPCClient: wraps the reply task in withTaskCancellationHandler and bridges the continuation through a small resume-once box (XPCReplyBox). On cancellation the continuation is resumed promptly; a late XPC reply becomes a no-op. The box guarantees the continuation is resumed exactly once. The connection is left intact on timeout; only the pending request is abandoned.

Testing

• Tested locally
• Added/updated tests
• Added/updated docs

Verified by static / code-level review; not built locally (no macOS 26 toolchain available here) — CI build will validate.

[stephenlclarke]

I validated this implementation on current Apple main as the first standalone commit of #1935, preserving the original author and code unchanged. The follow-up commit adds deterministic coverage for timeout return, caller cancellation, late replies, client reuse after timeout, cancellation before continuation storage, and unknown-route replies. If preferred, those tests can be folded into this PR; #1935's separate functional delta is the shorter root-help plugin-discovery policy.

[JeronimoColon]

I can confirm the illusory-timeout half of this from an independent reproduction against a stock 1.1.0 install, hit while building on ContainerAPIClient.

ContainerClient.copyOut sends its request with a 300 second responseTimeout. Point it at a guest path that does not exist (the #1927 stall) and the call does not return at 300 seconds. In my capture it sat for about sixteen minutes, and it returned only when I killed the container's runtime helper so the daemon could finally send back an error. The error that then surfaced was the timeout's own "XPC timeout for request to com.apple.container.apiserver/containerCopyOut" - selected at the 300 second mark, then stuck behind the wait on the non-cancellable reply continuation, exactly as this PR describes. The diagnosis matches what the wire actually does.

Two notes from reading the change:

• The resume-once handoff checks out, including the racy corner: onCancel can fire before store installs the continuation, and the pending stash covers that ordering, so neither side can double-resume or drop a resume. The timeout path also surfaces the intended timeout error rather than the reply task's CancellationError, since group.next() selects the timeout first and the cancellation error is discarded in the group teardown.
• Consider a small unit test on XPCReplyBox itself: store-then-resume, resume-then-store, and a second resume as a no-op. The resume-once invariant is what stands between this fix and a trapped double resume, and it is testable without a live XPC connection.

Worth cross-linking #1927: with this change that cp fails at its 300 second budget with a clear timeout error instead of hanging until reboot, independent of the guest-side fix in apple/containerization#799. I built the same shape of fix (a resume-once race around the non-cancellable send) into my own client layer and it has held up. Good to see it proposed upstream.