iOS reboot-safe monotonic evidence: guarantees of POSIX semaphore continuity on iOS 16+?

For an application supporting iOS 16 and later, including iOS 18 and newer releases, I would like to clarify the supported guarantees for deciding whether persisted monotonic time evidence belongs to the current boot.

I have read the DTS reply in “Time verification in iOS 18+” and the linked recommendation to use CLOCK_MONOTONIC with an exclusively created POSIX named semaphore:
https://developer.apple.com/forums/thread/774658?answerId=825483022#825483022
https://developer.apple.com/forums/thread/110044?answerId=754364022#754364022

That recommendation describes semaphore cleanup on restart as a reasonable assumption. My question is specifically about the documented guarantees and safe failure conditions of that approach, rather than another request for a replacement for kern.bootsessionuuid.

The required distinction is between process or application-engine restarts during the same boot and an actual device reboot. A continuity mechanism should remain valid across the former and distinguish, or safely invalidate, observations retained across the latter. It must not depend on an assumed-stable wall clock or on comparing uptime magnitudes that could overlap after a reboot.

For an App Group-namespaced semaphore on supported iOS versions:

1. Is cleanup at every device reboot, and persistence across ordinary process termination or suspension within a boot, a documented guarantee that an application may rely on?
2. What sandbox, resource-limit, lifecycle or name-reuse conditions can invalidate that inference? Is there a supported way to avoid treating a recreated or unrelated same-name semaphore as proof that older persisted observations belong to this boot?
3. If those guarantees cannot be established, is there another supported boot-continuity mechanism? Please identify its OS availability and applicable privacy or required-reason API constraints. No raw boot identifier or raw uptime needs to be sent off-device.

If supported cross-process continuity cannot be established, is a continuously alive native process's sleep-inclusive monotonic clock a documented comparison domain until that process ends? In that narrower design, all previous-process observations would be invalidated, accepting the loss of same-boot recovery. A process UUID or application-engine identity would not be treated as an operating-system boot identity.

I am seeking documented guarantees, limitations or supported alternatives, not an undocumented sysctl or an inference from macOS behavior. This question concerns clock-domain continuity; it does not assume that continuity alone proves when a location observation was originally acquired.