fix: resolve plugin host root from published dist layout

[KehaoC]

Summary

Fixes plugin host package linking for published builds by resolving the real @jackwener/opencli package root from the running module path instead of assuming it is always one directory up.

In published installs, src/plugin.ts compiles under dist/src/plugin.js, so the old dirname + '..' logic could point plugin node_modules/@jackwener/opencli at dist/ instead of the package root. That breaks package export resolution for imports like @jackwener/opencli/registry.

Changes

• Add resolveHostOpencliRoot() to walk upward until it finds the host package package.json.
• Use that helper for plugin host symlinking and esbuild binary lookup.
• Add a regression test for resolving from a compiled dist/src/plugin.js layout.

Validation

• npm test -- --run src/plugin.test.ts
• npm run typecheck

Fixes #843
Refs #722

[Astro-Han]

Reviewed top to bottom against our AGENTS.md framework.

No P0 to P3 findings.

This is a meaningful and focused fix. It addresses the root cause in published builds, where resolving the host root from the module path could land on dist/ instead of the package root, which then broke plugin host linking and package export resolution.

Scope is tight, the helper is reused in both affected call sites, and the added regression test covers the dist/src layout that triggered the bug.

LGTM.

[jackwener]

LGTM. Clean fix.

Problem: path.dirname(thisFile) + '..' assumed the module is always one level deep (src/plugin.ts or dist/plugin.js). But in published builds, the compiled file lives at dist/src/plugin.js — two levels deep — so .. resolves to dist/ instead of the package root, breaking plugin host symlinks and esbuild resolution.

Solution: resolveHostOpencliRoot() walks upward from the current file until it finds a package.json with name: '@jackwener/opencli'. Falls back to the old dirname + '..' if nothing matches, preserving backward compatibility.

Review notes:

• Walk-up logic is correct — checks pkg.name to avoid stopping at nested package.json files (e.g. in node_modules)
• The catch {} on JSON parse is appropriate — a malformed package.json shouldn't halt the search
• Both call sites (linkHostOpencli and resolveEsbuildBin) are updated
• Regression test covers the exact scenario (dist/src layout)
• CI all green

No issues found.