IkeServiceManager.resolvePluginServiceLoaderPath() is macOS-specific; breaks plugin discovery on Windows/Linux

[kec]

Summary

IkeServiceManager.resolvePluginServiceLoaderPath() (common/src/main/java/dev/ikm/tinkar/common/service/plugin/IkeServiceManager.java:181–247) navigates from jpackage.app-path using a hardcoded macOS .app bundle layout (<contents>/runtime/Contents/Home/plugin-service-loader/). On Windows and Linux, jpackage produces a flat layout (<install>/runtime/plugin-service-loader/), so the probe always fails and the plugin system silently disables itself.

User-visible symptom is filed against the desktop installer:
ikmdev/komet-desktop#2 — Rocks KB menu items missing on the Windows MSI installer.

Fix

Anchor discovery on java.home instead of jpackage.app-path. java.home already points at the runtime root on every platform jpackage and jlink target:

Platform	java.home
macOS jpackage	Komet.app/Contents/runtime/Contents/Home
Windows jpackage	<InstallDir>\runtime
Linux jpackage	<install>/lib/runtime
jlink launcher	<image-root>

So Path.of(java.home).resolve("plugin-service-loader") is correct on all four. This mirrors the working anchor in App.resolveRuntimeDirectory("plugins") (komet-desktop) and lets both probes share semantics.

Probe order (proposed)

1. java.home/plugin-service-loader/ — covers jpackage (mac/win/linux) and jlink launcher
2. <parent-of-user.dir>/plugin-service-loader/ — jlink image launched from bin/
3. <user.dir>/target/plugin-service-loader/ — local Maven build

Existing PATH_KEY system-property override stays in place for explicit configuration.

Verification

• macOS: existing behavior preserved (Rocks KB menu items continue to load).
• Windows: Rocks KB menu items appear in the MSI build.
• Linux: same; verify against an RPM build if available.
• Unit-testable: the path-probing helper can be exercised against an in-memory FS fixture.