[Code Quality][P2] NAPI async complete 回调忽略 napi_status，取消/失败路径被业务结果吞并

[daugf2527]

问题描述

SwitchGameAsync 与 WaitForEngineStateAsync 的 complete 回调虽然接收了 napi_status status，但当前实现完全忽略该参数，并且无条件 napi_resolve_deferred(...)。

这会把“异步任务被取消/执行失败”等宿主层状态，混同为业务层 true/false 结果，导致 JS 侧无法区分：

• 真正执行完成（业务失败）
• 异步工作被取消（如 napi_cancel_async_work）
• 宿主/NAPI 层异常

代码证据

• 忽略 status 并直接 resolve：
  • entry/src/main/cpp/app/napi/libretro_engine_napi.cpp:537
  • entry/src/main/cpp/app/napi/libretro_engine_napi.cpp:545
  • entry/src/main/cpp/app/napi/libretro_engine_napi.cpp:963
  • entry/src/main/cpp/app/napi/libretro_engine_napi.cpp:971

官方/权威依据

• N-API async complete 回调会收到 napi_status，取消场景会以 napi_cancelled 进入 complete 回调：
  • https://nodejs.org/api/n-api.html#simple-asynchronous-operations
  • https://nodejs.org/api/n-api.html#napi_cancel_async_work

影响

• ArkTS/JS 侧无法精确判断“取消 vs 业务失败”，错误恢复与重试策略会被误导。
• 生命周期收敛阶段（Stop/Unload 与异步调用交错）的诊断信息丢失。

修复建议

1. 在 complete 回调先判断 status：
   • napi_ok：按业务结果 resolve。
   • 非 napi_ok（尤其 napi_cancelled）：reject Promise（或结构化错误对象）。
2. 为取消/失败路径补充日志与错误码映射，避免被业务 false 吞没。
3. 与现有 #28 的 create/queue 返回值检查形成完整闭环（create/queue/complete 全链路）。

验收标准

• complete 回调对 status 有显式分支处理。
• JS 侧可区分“业务失败”和“异步任务取消/宿主失败”。
• 取消路径不会再被静默 resolve 为普通 false。