fix(windows): load WinTray via Nucleus content-addressed cache

[kdroidFilter]

Fixes NucleusFramework/Nucleus#534 and #426.

Two Windows processes that both depend on ComposeNativeTray used to extract WinTray.dll to the same fixed cache path. A System.load from the first process locks the file, so the second process either hits AccessDeniedException on Files.move(REPLACE_EXISTING) or overwrites the locked DLL and then fails to load it.

The SHA-256 skip already shipped in 2.0.3 only helps when both processes have identical bytes. Different versions, a local rebuild, or a cold-start race still try to replace the shared file.

Summary

• Drop the forked NativeLibraryLoader and load Win/Linux/macOS tray natives through dev.nucleusframework.core.runtime.NativeLibraryLoader
• Extract into Nucleus's content-addressed cache (%LOCALAPPDATA%/nucleus/native/<platform>/<crc-size>/) so versions never share a file and an existing extract is never replaced
• Align resource platform dirs with Nucleus (win32-x64, win32-aarch64, linux-x64, darwin-x64)
• Evict libMacTray.dylib / libLinuxTray.so from the Nucleus cache after a native rebuild
• Add a two-JVM e2e test that loads two different WinTray binaries while the first process holds the DLL mapped

Test plan

• jvmTest — Issue534ReproTest (Windows denies Files.move onto a loaded DLL; second JVM with a different binary loads without AccessDeniedException). Also green on CI (natives + gradle).
• Launch two desktop apps that depend on ComposeNativeTray at the same time on Windows — two JVMs on this branch both System.load WinTray and stay alive together (two same-version processes can both load WinTray).
• Repeat with two different ComposeNativeTray versions installed — 2.0.3 fixed-path loader holds %LOCALAPPDATA%\composetray\native\win32-x86-64\WinTray.dll while this branch loads from the Nucleus content-addressed cache (published 2_0_3 and this branch can load WinTray at the same time).