Pre-activation authorization and inactive connection cleanup for a launchd Mach service

I am evaluating the supported macOS C XPC lifecycle for a separately installed system-domain Mach service. This is a design/documentation question, not a reported crash or a tested OS-specific failure. Please identify applicable macOS/SDK versions and public API guarantees; no installed SDK capability is being assumed.

The threat model includes an unprivileged process running as the worker's user. The OS and privileged administrator are trusted. Executables and role assignments would require independently protected approval. Matching a code signature alone is not intended to grant an issuer role.

Two API boundaries affect whether the service can be authorized before activation:

1. Binding an actual launch instance to protected enrollment. Is there a supported public API or enforceable launch-environment constraint that can distinguish an instance launched through an approved system-domain job/enrollment from direct invocation of the same approved executable? The required distinction is the actual job/executable launch transaction before service activation, not a process-provided label, PID/PPID lookup, copied install record, or signature alone. If launch constraints can enforce only a narrower property, what exactly is that property and its minimum supported version? If no public mechanism provides the stronger binding, confirmation of that limit would be useful. This question does not assume an XPC peer requirement can establish job origin or issuer authority.

2. Disposing of a newly owned inactive connection after setup failure. Suppose xpc_connection_create_mach_service returns a caller-owned inactive client or listener, but preactivation policy setup then fails, for example xpc_connection_set_peer_code_signing_requirement returns an error. What is the documented safe cleanup sequence if transport activation has not been authorized? The xpc_connection_activate documentation warns that last-release of a created inactive connection is undefined. The cancellation documentation describes asynchronous unwinding, but I have not found an explicit exception for last-release of a never-activated, canceled object. Does a supported cancel/release sequence exist? If activation is required even for disposal, what effects can that cleanup activation cause and what guarantees apply? I am asking about a newly created owned object, not an incoming borrowed peer that a listener can reject by canceling and returning.

Relevant references already consulted:

• https://developer.apple.com/documentation/xpc/xpc_connection_activate(_:)
• https://developer.apple.com/documentation/xpc/xpc_connection_cancel(_:)
• https://developer.apple.com/documentation/xpc/xpc_connection_set_event_handler(::)
• https://developer.apple.com/forums/thread/837286 (received-message checking versus initial outgoing delivery)

An API reference, versioned contract, or explicit statement that either guarantee is unavailable would help determine the safe supported boundary. I am not requesting private APIs or a workaround that treats a caller assertion as authorization.