Add iOS support for TapADN package

TapADN自动加载策略分析报告.md

@@ -59,7 +59,7 @@ TapADN / Dirichlet Unity 文档对 auto 的描述主要是“加载和展示合
 本地 SDK 注释进一步约束了能力边界：
 
 * `PreLoad` 当前只有 type=3，即激励视频，会被 native SDK 处理。
-* iOS auto-ad / preload 在当前 wrapper 中返回不支持或 noop。
+* iOS 没有官方 native auto 缓存语义；当前模块会对激励、插屏、开屏 auto API 做 load-then-show 兼容 fallback，`PreLoad` 仍为 noop。
 * Android bridge 中为 auto ad 保留了 singleton `DirichletAdNative`，用于保持 native 侧自动广告缓存。
 
 当前接入严格遵循了这些 TapADN API，但没有也不能补出 TopOn 那种场景入口，因为当前 SDK wrapper 没有暴露同类接口。`ADManager.EnterAdScenario(...)` 对 TapADN 玩家侧目前没有平台上报效果，只能作为项目自身策略或日志的入口继续扩展。
@@ -73,7 +73,7 @@ TapADN / Dirichlet Unity 文档对 auto 的描述主要是“加载和展示合
 * 开屏在中国安卓渠道更常见，但冷启动时长、首屏流失和合规压力都更敏感。若 auto show 触发后再加载，失败或超时都直接影响进主场景体验；生产上更适合手动加载、严格超时和无广告快速进入。
 * 顶级 IAA 调优更关注 placement / scenario 维度，而不是“这个类型是不是 auto”。同一个激励视频，复活、翻倍金币、免费抽奖的 eCPM、转化率和留存影响都可能不同，需要可分桶、可频控、可 A/B。
 
-所以，模块层应该把 auto 当作“TapADN Android 的一种展示通道”，而不是全局商业化策略本身。
+所以，模块层应该把 auto 当作“TapADN Android 的一种展示通道”；iOS 兼容 fallback 只能保证回调链路完整，不应被当成同等的 native 缓存策略。
 
 ## 推荐默认配置
 
@@ -136,7 +136,7 @@ tapadn.splash_prewarm_on_init=false
 
 ## 当前实现评价
 
-当前 TapADN auto 接入本身是合规且完整的 API 级接入，但默认策略偏激进。它适合样例工程、快速调试和 Android 单平台验证；对于正式 IAA 游戏商业化，建议把默认认知改成：
+当前 TapADN auto 接入本身是合规且完整的 API 级接入，但默认策略偏激进。它适合样例工程和快速调试；对于 Android/iOS 同步上线的正式 IAA 游戏商业化，建议把默认认知改成：
 
 * TapADN auto 负责“SDK 内部 load + show + 缓存复用”。
 * 项目商业化策略仍然负责“场景进入、ready gating、频控、冷却、奖励发放、A/B 分桶和兜底路径”。