Stop stripping versionless local plugin paths at parent '@' dirs

derivePluginNameFromKey() now removes everything after the last @ before checking whether the key is a file:// URL or filesystem path. For versionless local entries like file:///tmp/@work/oh-my-opencode or /tmp/@work/oh-my-opencode, that truncates the path at the parent directory, so discovery derives the wrong plugin name. Because discoverInstalledPlugins() feeds plugin.name into the namespacing logic in command-loader.ts, agent-loader.ts, and skill-loader.ts, those plugins expose the wrong plugin:command/plugin:agent/plugin:skill names and can collide with unrelated plugins whenever any parent directory contains @.

Useful? React with 👍 / 👎.

Avoid host-OS resolve() for platform-specific config paths

Using resolve() here makes config discovery depend on the host OS path rules instead of the target platform branch. I verified this against the existing Windows-path test in src/shared/opencode-config-dir.test.ts: when the suite runs on Linux/macOS and mocks process.platform = 'win32', resolving C:\Users\TestUser\AppData\Roaming\... prepends the repo cwd, so getOpenCodeConfigDir({ binary: "opencode-desktop" }) returns an invalid path and the shared test now fails. Any other non-Windows code path that needs to inspect Windows-style config locations will hit the same regression.

Useful? React with 👍 / 👎.

P2: resolve(pathValue) uses host-OS path semantics, not the target platform's. When running on Linux/macOS with process.platform mocked as 'win32', getTauriConfigDir returns a Windows-style path (e.g. C:\Users\...), but resolve() treats it as relative (not a Unix absolute path) and prepends CWD, producing an invalid path. This breaks cross-platform tests such as the existing Windows-path test in opencode-config-dir.test.ts.

Consider skipping resolve() when the path is already absolute on its target platform, or guard the resolve call so it only normalizes paths that match the host OS conventions.

Check if this issue is valid — if so, understand the root cause and fix it. At src/shared/opencode-config-dir.ts, line 46:

<comment>`resolve(pathValue)` uses host-OS path semantics, not the target platform's. When running on Linux/macOS with `process.platform` mocked as `'win32'`, `getTauriConfigDir` returns a Windows-style path (e.g. `C:\Users\...`), but `resolve()` treats it as relative (not a Unix absolute path) and prepends CWD, producing an invalid path. This breaks cross-platform tests such as the existing Windows-path test in `opencode-config-dir.test.ts`.

Consider skipping `resolve()` when the path is already absolute on its target platform, or guard the `resolve` call so it only normalizes paths that match the host OS conventions.</comment>

<file context>
@@ -42,14 +42,25 @@ function getTauriConfigDir(identifier: string): string {
 }
 
+function resolveConfigPath(pathValue: string): string {
+  const resolvedPath = resolve(pathValue)
+  if (!existsSync(resolvedPath)) return resolvedPath
+
</file context>

P2: Existing tests still assert raw directory strings even though getLoadedPluginVersion() now returns canonicalized real paths, which can fail on macOS/symlinked environments.

Check if this issue is valid — if so, understand the root cause and fix it. At src/cli/doctor/checks/system-loaded-version.test.ts, line 108:

<comment>Existing tests still assert raw directory strings even though `getLoadedPluginVersion()` now returns canonicalized real paths, which can fail on macOS/symlinked environments.</comment>

<file context>
@@ -104,6 +104,31 @@ describe("system loaded version", () => {
       expect(loadedVersion.loadedVersion).toBe("2.3.4")
     })
+
+    it("resolves symlinked config directories before selecting install path", () => {
+      //#given
+      const realConfigDir = createTemporaryDirectory("omo-real-config-")
</file context>