[krisnye]

Fixes the kernel plugin binding compiled code to its own copy of @adobe/ecs instead of the copy the app uses.

Bug

An app's node_modules/@adobe/ecs was linked to a local checkout while its lockfile also pinned the npm copy. In its tests, the modules the kernel plugin transformed bound to one copy and everything else to the other. With two registries, a run failed with "… isn't a registered resource".

Cause

paths.ts built every path the plugin injects or recognizes from the plugin's own import.meta.url:

• the hooks attach-kernel, prepared-spawn and prepared-lookup;
• the package index;
• the System, Rule, Finalizer, Index and intrinsic module sets.

So a module importing a different copy was either left uncompiled, because its System import wasn't recognized, or had imports injected into the plugin's copy.

Fix

• The plugin finds a module's copy by going up from the resolved file to the nearest package.json named @adobe/ecs, cached per directory.
• Injected imports and namespace recognition use that copy, so compiled code binds to the registry its importer uses.
• In-repo behavior is unchanged.

No public contract changes; only internal compiler code. The version is 0.1.1, the same edit #219 makes, so this PR contains #219's change and #219 can be closed.

Test

plugin.test.ts adds a project whose node_modules/@adobe/ecs is a separate copy of the built package. Its kernel module gets the hooks injected from that copy and its System declaration gets an id. It was red before the fix ("nothing injected") and is green after. pnpm run build and pnpm test in packages/ecs pass: 133 files and 1006 tests.

🤖 Generated with Claude Code