Docs suggestion: call out actor-reentrancy pitfall in the "caching a Worker" migration guide

Summary

The Caching a Rive File / Worker guide recommends lazily creating and caching a single Worker behind an actor

https://github.com/rive-app/rive-docs/blob/3fe8efc468acc290763be1535a8b59b7ae1c513b/runtimes/apple/migrating-from-legacy.mdx?plain=1#L64-L82

This pattern is a check-then-await-then-write sequence. Because await Worker() is a suspension point, two callers racing worker() can both observe cachedWorker == nil before either has written the result, leading to Worker() being constructed twice (wasted init cost, and briefly two live Worker/CommandServer instances). actor/@MainActor isolation prevents data races here, but not this logic race (reentrancy across an await), so neither the compiler nor Thread Sanitizer catches it.

We ran into exactly this in our app and ended up caching the in-flight Task instead of the value:

actor WorkerProvider {
    @MainActor private var cachedWorker: Worker?
    @MainActor private var loadingTask: Task<Void, Error>?

    @MainActor
    func worker() async throws -> Worker {
        if let cachedWorker { return cachedWorker }

        let task = loadingTask ?? Task {
            cachedWorker = try await Worker()
        }
        loadingTask = task

        try await task.value
        return cachedWorker!
    }
}

Start with runtimes/apple/migrating-from-legacy.mdx, especially the linked lines in the “Caching a Rive File / Worker” guide. Explain that caching a Worker behind an actor can still construct it twice when initialization suspends, and document the in-flight Task approach shown in the issue. Done means the migration guide clearly calls out the reentrancy pitfall and its suggested mitigation.