背景

commit 5aa350f4 feat: add loadErrInfo for LoadNativeModule to return precise error info 为 NativeModuleManager::LoadNativeModule 新增了第 7 个参数 std::string* loadErrInfo，并在加载失败路径上引入了 ClassifyLoadError 做错误归类。该提交引入了两个回归问题：

问题 1：ClassifyLoadError 空指针解引用（崩溃）

module_manager/native_module_manager.cpp 中：

} else if (ctx.isAppModule && !ctx.pathRegistered) {
    *loadErrInfo = std::string("app lib path not registered in namespace '") + ctx.path + "'";
}

ctx.path 未判空。当 isAppModule == true 且 path == nullptr 时：

1. LoadNativeModule 入口仅校验 moduleName 与 relativePath，未校验 path。
2. 多个调用方直接传 nullptr 作为 path（ark_native_engine.cpp:825 / :828 / :1526），isAppModule 由上层决定可为 true。
3. FindNativeModuleByDisk 中，path == nullptr 时 IsExistedPath(nullptr) 返回 false（内部 pathKey && ... 短路），因此 dlopenFailed 保持 false。
4. 走到 ClassifyLoadError 的 else if (ctx.isAppModule && !ctx.pathRegistered) 分支 → std::string + nullptr → UB（libc++ 下基本必崩）。

触发场景：应用侧 NAPI 模块 .so 与 .abc 均加载失败（打包错误/缺符号等），且走 4 参或 GetModuleFromName 调用路径。

问题 2：LoadNativeModule ABI 破坏（三方应用调用失败）

签名变更：

// 改前（三方 App 链接的 mangling）
NativeModule* LoadNativeModule(const char* moduleName, const char* path, bool isAppModule,
    std::string& errInfo, bool internal = false, const char* relativePath = "");

// 改后（当前 master）
NativeModule* LoadNativeModule(const char* moduleName, const char* path, bool isAppModule,
    std::string& errInfo, bool internal = false, const char* relativePath = "",
    std::string* loadErrInfo = nullptr);

Itanium C++ ABI 下默认参数不进 mangled name，参数个数变化 → 老 mangled 符号消失。三方应用通过 dlopen(libace_napi.z.so) + 调用旧 6 参签名在新 so 上找不到符号 → 运行期解析失败。

期望

1. 在 ClassifyLoadError 内对 ctx.path 做判空（局部修复，不改加载行为）。
2. 新增 6 参 LoadNativeModule 重载以保留旧 mangled 符号导出，行为委托到 7 参主版本（loadErrInfo = nullptr）。