Greptile Summary

This PR fixes alias resolution for user-installed openclaw plugins that live outside the package tree (e.g. ~/.openclaw/extensions/…) by threading process.argv[1] as a package-root hint through buildPluginLoaderAliasMap into resolvePluginSdkAliasFile and resolvePluginSdkScopedAliasMap. A targeted regression test models the external-plugin scenario end-to-end.

• Core fix: buildPluginLoaderAliasMap now passes argv1: process.argv[1] to both resolvePluginSdkAliasFile and resolvePluginSdkScopedAliasMap, which forward it to resolveLoaderPluginSdkPackageRoot. Previously, resolveLoaderPluginSdkPackageRoot had no implicit process.argv[1] fallback (unlike resolveLoaderPackageRoot), so external plugins would silently fail to resolve the correct SDK package root.
• API surface: listPluginSdkExportedSubpaths and resolvePluginSdkScopedAliasMap each gain an optional argv1 parameter. Callers that don't pass it continue to work as before.
• Caching: Unaffected — cache keys are derived from the resolved packageRoot (and candidate ordering), not from the argv1 input, so different argv1 values that resolve to different roots are cached independently.
• resolveExtensionApiAlias intentionally does not receive an explicit argv1, because resolveLoaderPackageRoot (which it calls) already reads process.argv[1] via its own params.argv1 ?? process.argv[1] fallback.
• Test helper: withArgv1 directly reassigns process.argv (rather than using vi.spyOn) because process.argv is a mutable array property; it restores the original reference in a finally block, consistent with the existing restore-in-finally pattern used elsewhere in the test file.

Confidence Score: 5/5

• Safe to merge — change is minimal, correctly scoped, and covered by a new regression test.
• The fix is a focused two-line change in buildPluginLoaderAliasMap plus parameter threading through two existing functions. The caching strategy is unaffected. The only behavioral change is additive: external plugins that previously fell back to weaker heuristics now pick up the correct SDK root via the running CLI path. The new regression test models the exact failing scenario from the linked issues. No existing tests are modified, and the overall pattern is consistent with how resolveLoaderPackageRoot already handles argv1.
• No files require special attention.

_{Reviews (1): Last reviewed commit: "Plugins: resolve sdk aliases from the ru..." | Re-trigger Greptile}