fix(desktop): bump Clerk Electron SDK to 0.0.24 and register t3code:// scheme on Linux - #5015

💭 I see the previous fix addressed how resolveUserDataPath gets the DesktopEnvironment from the context. Now I'm checking how make is using Effect.provide with the context to eliminate the dependency, making the return type have R = never. I'm checking whether the pattern of using Effect.provide(yield* Effect.context<...>()) to strip requirements from a service field violates conventions—specifically, whether resolveUserDataPath should have R = never when it's capturing context to eliminate its DesktopEnvironment and FileSystem dependencies. Now I'm noticing that DesktopClerk.make is yielding the standalone DesktopAppIdentity.resolveUserDataPath Effect rather than depending on the DesktopAppIdentity service itself. The conventions expect importing services as namespaces with their public shape (.make, .layer), but here it's consuming a raw exported helper Effect instead of going through the service boundary. This feels like it might be hiding a dependency — though technically the types work out since resolveUserDataPath requires FileSystem and DesktopEnvironment, which make already needs. It's borderline whether this counts as a convention violation or just an acceptable shared pure helper. There's also the side effect of electronApp.setPath happening during layer construction, but since electronApp is an Effect service, that's fine. Then in configure, there's Effect.runPromiseWith(context) being used inside an electron callback. The runPromise call at the native callback boundary is allowed by conventions, and checking the diff shows this existed before — only the condition changed. The bridge.isPrimaryInstance check is fine too. Looking back at my earlier comment, I'd suggested using Effect.fn for resolveUserDataPath, and that's actually what was there before, so this is now fixed. In the tests, service instances are passed explicitly which is allowed, and FileSystem.layerNoop is fine. The removal of requestSingleInstanceLock from ElectronApp is acceptable. There's a potential concern about DesktopClerk duplicating logic ownership with resolveUserDataPath — it's used by both DesktopAppIdentity's service and DesktopClerk itself. But they do use namespace imports and the exported effect legitimately acquires its own dependencies from the environment, so this seems acceptable. The Effect.provide(yield* Effect.context<...>()) pattern I recommended is being used correctly, and DesktopAppIdentity's service field type has no problematic requirements. Let me verify the imports in the touched files are using subpath namespaces rather than consolidated imports from "effect", and quickly scan the test files for any convention violations. I'm noticing that DesktopApp.ts also calls appIdentity.resolveUserDataPath around line 230 to set the userData path, which means DesktopClerk is duplicating this logic. It's not really a convention issue, more of a potential behavior redundancy. I think the review is solid overall, and I'm trying to figure out how to format the response since the instructions say to output "All clear" if there are no findings, but it needs to be JSON matching the schema.