iOS uni-app X 5.26 自接原生穿山甲仍弹 -9001：支持范围及修正方案？

我们使用 iOS uni-app X 5.26 系列原生运行库，通过自有插件直接接入穿山甲原生 SDK，业务没有采用 uni-ad 广告调用。

现象与已核事实：

1. 按官方原生模块构建文档，已从构建及整包依赖中排除未使用的 uni-ad 模块源码、注册、DCUniAdFoundation 和 DCUniAdSDK.bundle，保留原生穿山甲能力。
2. 0501 广告专项包的五个广告位在实机显示正常，那轮样本未再看到 -9001，但未取得完整检测周期或判定，因此不能认定根治。
3. 后续 0504 测试包补齐了同版微信 SDK 配置及 Objective-C 分类链接。小程序实际内容已可打开；从微信正常返回 App 时，实机再次出现“应用的 uni-AD 业务状态异常（-9001），请登录 https://uniad.dcloud.net.cn 处理”。该返回场景已再次复现。
4. 前述包的核心运行库和原生穿山甲插件二进制未更换；去除外置 uni-ad 模块的结果仍保留。尚不能确定近期微信变更是否间接触发，或只是之前样本未覆盖，不能把二进制未变当作无回归证明。

希望优先请官方明确：

一、uni-app X 5.26 的 iOS 原生 SDK，是否正式支持“不使用 uni-ad、直接接入原生穿山甲”的方式？如果支持，请给出本场景需要的官方配置或确切修正版本及兼容要求；如果存在限制，请明确适用产品、版本和受支持的处理路线。

我们看到 https://nativesupport.dcloud.net.cn/AppDocs/usemodule/iOSModuleConfig/uniad.html 的注意事项，在业务状态提醒场景下建议删除自行集成的穿山甲/广点通并申请 uni-ad。但该页属于 AppDocs 的 iOS 模块说明，不能确定是否同样适用于 uni-app X 5.26，希望先澄清这一支持边界。

二、如果支持直接原生接入，如何通过正式支持的只读接口或诊断工具，取得一次自然检测周期的实际判定？

当前公开 UniADImpl.h 只有 startDetectionWithContext、updateDetectionContext、create、isEnded，没有明确的结果订阅或结构化诊断导出；我们没有把 isEnded 推定为检测周期结束。一次被动本进程系统日志未取得判定字段，穿山甲初始化成功回调也不能替代 Runtime 的检测结论。已有静态调用记录表明，本地 evidence/snapshot 的 requiresToast 即可触发提示，不一定需要先有服务端错误响应。

最小诊断需要同周期本地关联号和单调时间、platform/mode、配置/初始化及匹配状态、verdict/illegalReason、requiresToast，以及是否使用缓存判定。标识只需存在/配置匹配布尔值，不需要 AppID 原值或哈希；网络响应错误仅在确实参与判定时作为可选关联。请提供受支持的获取方式及启用、撤回步骤，或说明此版本缺少该能力。

三、官方 https://uniapp.dcloud.net.cn/release-note-alpha-archive.html#_3-2-12-20211028-alpha 记录过 Android 已开通增强广告、部分设备首次启动误报 -9001 的修复；同版 iOS 只是广告 SDK 更新。我们不据此认定当前 iOS 问题同根，请确认当前场景是否存在类似误报及准确适用的修正版本。

本次仅咨询支持范围和技术修正方案。未修改 Runtime、未私调检测器、未 hook 或隐藏提示，也未清数据或改变隐私同意状态。本文不附源码、安装包、原始日志、截图、AppID/哈希、账号、设备标识、凭证或广告标识；若确需补充材料，请先说明必要字段，待另行脱敏确认。