fix(xim): elfpatch loader-provider resolution follows additive materialization

[Sunrisepeak]

Problem (independent of the mcpp OpenCV fix)

Under xlings' additive (project-over-global) model, elfpatch resolved a runtime dep's provider install_dir from the plan node's nominal storeRoot (or the pkginfo.dep_install_dir scan). When a project-scoped consumer reuses a loader-provider (e.g. xim:glibc) materialized only in the global store, the consumer's PT_INTERP got pointed at a project store where the provider was never laid down → dangling interpreter.

Fix (D1, root-cause)

• effective_install_dir_(node) — the store where a node's payload is actually materialized, checked via the scoped version DBs in additive order (project_versions → global_versions), judged by the version-DB record (not "dir non-empty", which .xpkg.lua fools).
• deps_exports build + locate_dep_install_dir_ now use it, unifying build-dep PATH and elfpatch onto one resolution.
• In-memory only — does NOT reintroduce the reverted feat(xim): persist declared xpkg exports to .xpkg-exports.json #351 persisted .xpkg-exports.json.

Pairing / sequencing (maintainer input needed)

This pairs with a libxpkg change (branch fix/elfpatch-effective-install-dir on openxlings/libxpkg): DepExport.install_dir + push into in-memory _RUNTIME.deps_exports, and elfpatch.lua closure_lib_paths preferring the injected effective dir. That libxpkg branch currently sits atop the in-flight feat/xpm-v2-multiarch-main work, so base-branch sequencing (V2 first?) is a maintainer call — I did not auto-merge.

Verification

Builds (xlings 0.4.62); deterministic Lua harness proves the mechanism (effective global store resolves to the materialized loader; old nominal-scope path resolved to the empty project store); e2e regressions project_global_fallback_test.sh, project_local_repo_test.sh, pkginfo_install_dir_test.sh pass.

Design: .agents/docs/2026-07-09-scope-consistency-installed-check-and-loader-resolution.md

Independent of the OpenCV/cmake failure (fixed in mcpp-community/mcpp#205).

https://claude.ai/code/session_01Y3KE7MAE8yV7BG35eXy7FV

[Sunrisepeak]

⚠️ CI is expected-red pending a dependency-ordered release — converting to draft.

installer.cppm:1388 references DepExport.install_dir, a new field this PR's paired libxpkg change adds (openxlings/libxpkg branch fix/elfpatch-effective-install-dir). xlings pins mcpplibs-xpkg 0.0.41/0.0.42 (xmake.lua:45, mcpp.lock), which don't have the field yet → has no member named 'install_dir'.

Dependency chain to land this:

1. Merge the libxpkg elfpatch change → release libxpkg 0.0.43 → bump mcpp-index pkgs/x/xpkg.lua.
2. Bump this repo's pin (xmake.lua add_requires + mcpp.lock) to 0.0.43 → CI passes → merge.

The libxpkg fix branch currently sits atop the unmerged feat/xpm-v2-multiarch-main (V2 schema / 0.0.42) work, so the V2-merge-to-main + release sequencing is a maintainer call — I did not force it. The code is implemented + locally verified (builds xlings 0.4.62; deterministic + 3 e2e regressions pass). Independent of the OpenCV fix (mcpp-community/mcpp#205, already merged).

[Sunrisepeak]

Closing per reassessment: this elfpatch additive-materialization fix (D1) is an INDEPENDENT robustness gap, NOT triggered by the opencv/cmake failure (whose only needed fix is mcpp 0.0.87, already shipped). No current package exercises its scenario (project-scoped dynamic executable runtime-depending on a global-only loader-provider); opencv CI already gets past the loader stage on plain 0.0.87. Reopen when a real use case appears. Detailed reassessment: mcpp-index .agents/docs/2026-07-09-install-hook-toolchain-build-env-gap.md + the D1 design doc.