CLMonitor.init crash - same signature as thread 771001, but NOT initialized at library load time

We're experiencing the same CLMonitor.init crash described in thread 771001, but our initialization timing is different from the original poster's - we do NOT initialize at library load time or during didFinishLaunchingWithOptions. Our CLMonitor is created lazily as a singleton on first access, after UIApplicationMain() has completed.

Our setup:

• iOS 17+ deployment target, Swift 6, strict concurrency
• CLMonitor is created as a singleton, lazily, on first access — triggered by either a location update (recentering the geofence via setFence) or the geofence event loop starting when the app enters background (didEnterBackground -> startGeofenceMonitoring)
• We use one CLMonitor.CircularGeographicCondition for geofencing (exit detection only)
• The CLMonitor singleton is @MainActor-isolated

What we've tried:

Pinned the Task that creates CLMonitor to @MainActor (Task { @MainActor in await CLMonitor("GeofenceMonitor") }). This didn't help - the crash still occurs because CLMonitor.init itself executes on the cooperative thread pool regardless of the calling task's actor isolation.

Our current code:

extension CLMonitor {
    @MainActor
    static var geofenceMonitor: CLMonitor {
        get async {
            @MainActor
            struct Static {
                static var task: Task<CLMonitor, Never>?
            }
            if let task = Static.task {
                return await task.value
            }
            let task = Task { @MainActor in await CLMonitor("GeofenceMonitor") }
            Static.task = task
            return await task.value
        }
    }
}

Questions:

1. Since the crash is entirely inside CLMonitor.init's internal synchronous dispatch to the CoreLocation shared queue, and there doesn't appear to be a Swift-level way to control which thread the ObjC-bridged initializer executes on - is there a recommended workaround?

2. Would migrating to the deprecated CLLocationManager.startMonitoring(for: CLCircularRegion) API avoid this crash path entirely? Our use case is simple (one circular geofence, exit-only detection) and we'd prefer a stable solution while this issue is being investigated.

3. Is this a known framework issue being tracked internally? Should we file a Feedback for it?