docs: state the native check + rescue floor uniformly as 10.52.1

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Author: sunnylqm

README-CN.md

@@ -32,15 +32,15 @@
 
 ### 原生冷启动检测
 
-自 10.51.0 起（鸿蒙为 10.52.1——此前版本因桥接缺陷该检测从未生效），每次冷启动后数秒会在后台线程执行一次**不依赖 app bundle** 的更新检查（下载、打补丁与状态切换全部在原生侧完成）。它的存在只为一件事：**当前热更版本坏到 JS 起不来时，仍有一条能把修复版拉下来的通路**——常规更新流程仍由应用内的 JS 负责，检查结果会被 JS 侧复用，不会重复请求。
+自 10.52.1 起，每次冷启动后数秒会在后台线程执行一次**不依赖 app bundle** 的更新检查（下载、打补丁与状态切换全部在原生侧完成）。它的存在只为一件事：**当前热更版本坏到 JS 起不来时，仍有一条能把修复版拉下来的通路**——常规更新流程仍由应用内的 JS 负责，检查结果会被 JS 侧复用，不会重复请求。
 
 几个需要知道的点：
 
 - **不阻塞启动**：延迟数秒、跑在后台线程，成果在**下次启动**生效。
 - **是否自动激活取决于你的配置**：`updateStrategy` 为 `silentAndNow` / `silentAndLater` 且未关闭自动检查（`checkStrategy` 不为 `null`）时，原生侧才会把下载好的版本设为下次启动生效；其余情况只下载，激活权仍在 JS。
 - **救砖指令**：控制台可按版本标记「强制启动」，被标记的版本无视上述策略直接在下次启动生效——这是把已被坏版本卡死的设备捞回来的手段。设备本地的崩溃回滚保护仍然优先，已回滚过的版本不会被再装回去。
-- **崩溃时刻救援**（10.52.0 起，Android 与 iOS）：应用在启动阶段死于未捕获的 JS 错误时，SDK 会短暂扣住垂死的进程（数秒、有硬上限），把检查与下载做完——即使版本每次启动零点几秒就崩，也能被换掉。该窗口内下载到的修复版一律设为下次启动生效（JS 已经没有机会做决策了）。崩溃上报不受影响：SDK 以链式方式保存并在结束后调用原有的崩溃处理器。不覆盖：原生（非 JS）崩溃、ANR、OOM 击杀，以及 iOS 上安装了自定义 `RCTSetFatalHandler` 的应用（那时 React Native 不再抛出本机制拦截的异常）。
-- **断点续传**（10.52.0 起）：更新下载在进程死亡后保留进度、下次以 HTTP Range 续传，反复的短命启动也能单调累积进度；紧随中断轮次的下一次启动会跳过延迟立即续传。鸿蒙不需要崩溃时刻扣留：RNOH 下未捕获的 JS 错误不会杀死进程，JS 启动即崩时原生检测照常完成（需 10.52.1——此前版本因桥接缺陷，原生检测在鸿蒙上从未生效）。
+- **崩溃时刻救援**（Android 与 iOS）：应用在启动阶段死于未捕获的 JS 错误时，SDK 会短暂扣住垂死的进程（数秒、有硬上限），把检查与下载做完——即使版本每次启动零点几秒就崩，也能被换掉。该窗口内下载到的修复版一律设为下次启动生效（JS 已经没有机会做决策了）。崩溃上报不受影响：SDK 以链式方式保存并在结束后调用原有的崩溃处理器。不覆盖：原生（非 JS）崩溃、ANR、OOM 击杀，以及 iOS 上安装了自定义 `RCTSetFatalHandler` 的应用（那时 React Native 不再抛出本机制拦截的异常）。
+- **断点续传**：更新下载在进程死亡后保留进度、下次以 HTTP Range 续传，反复的短命启动也能单调累积进度；紧随中断轮次的下一次启动会跳过延迟立即续传。鸿蒙不需要崩溃时刻扣留：RNOH 下未捕获的 JS 错误不会杀死进程，JS 启动即崩时原生检测照常完成。
 - **可以关闭**：`disableNativeCheck: true`。关闭后每次冷启动少一次后台请求，代价是**放弃上述自愈能力**——被坏热更卡死的设备将无法自动恢复。仅在这次请求本身构成问题时（流量/耗电预算、隐私清单申报、需用户同意后才可联网）才建议关闭。
 
 ### Diff 算法对比

README.md

@@ -30,15 +30,15 @@ See the docs:
 
 ## Native cold-start check
 
-Since 10.51.0 (HarmonyOS: 10.52.1 — earlier versions never armed the check there due to a bridging bug) every cold start runs one background update check a few seconds after launch that **does not depend on the app bundle** — the request, the download, the patch and the version switch all happen natively. It exists for exactly one reason: **when the running update is broken enough that JS never starts, something still has to be able to fetch the fix.** Normal updates remain the JS flow's job; the JS check reuses this result instead of issuing its own request.
+Since 10.52.1 every cold start runs one background update check a few seconds after launch that **does not depend on the app bundle** — the request, the download, the patch and the version switch all happen natively. It exists for exactly one reason: **when the running update is broken enough that JS never starts, something still has to be able to fetch the fix.** Normal updates remain the JS flow's job; the JS check reuses this result instead of issuing its own request.
 
 What to know:
 
 - **It never blocks startup**: it is delayed by a few seconds, runs off the main thread, and its result takes effect on the *next* launch.
 - **Whether it activates depends on your configuration**: only with `updateStrategy` set to `silentAndNow` / `silentAndLater` *and* automatic checks left on (`checkStrategy` not `null`) will the native side mark a downloaded version for the next launch. Otherwise it downloads and leaves activation to JS.
 - **Rescue directive**: the dashboard can mark a version "force boot", which activates on the next launch regardless of the strategies above — this is how a fleet stuck on a broken version is recovered. The device-local crash-rollback guard still wins: a version this device already rolled back from is never reinstalled.
-- **Crash-moment rescue** (since 10.52.0, Android & iOS): when the app dies of an uncaught JS error during startup, the SDK briefly holds the dying process (a few seconds, bounded) to finish the check and download — so even a version that crashes a fraction of a second into every launch gets replaced. In that window the downloaded fix is always activated for the next launch, since JS is no longer around to decide. Crash reporters keep working: the SDK chains the previous crash handler and always hands the crash over afterwards. Not covered: native (non-JS) crashes, ANRs, OOM kills, and — on iOS — apps that install a custom `RCTSetFatalHandler` (React Native then no longer raises the exception this rescue intercepts).
-- **Resumable downloads** (since 10.52.0): update downloads survive process death and resume from where they stopped (HTTP Range), so repeated short-lived launches still make monotonic progress; a launch that follows an interrupted round skips the startup delay and resumes immediately. HarmonyOS does not need the crash-moment hold: an uncaught JS error does not kill the process there, so the native check completes normally even when JS dies on launch (requires 10.52.1 — earlier versions never armed the native check on HarmonyOS due to a bridging bug).
+- **Crash-moment rescue** (Android & iOS): when the app dies of an uncaught JS error during startup, the SDK briefly holds the dying process (a few seconds, bounded) to finish the check and download — so even a version that crashes a fraction of a second into every launch gets replaced. In that window the downloaded fix is always activated for the next launch, since JS is no longer around to decide. Crash reporters keep working: the SDK chains the previous crash handler and always hands the crash over afterwards. Not covered: native (non-JS) crashes, ANRs, OOM kills, and — on iOS — apps that install a custom `RCTSetFatalHandler` (React Native then no longer raises the exception this rescue intercepts).
+- **Resumable downloads**: update downloads survive process death and resume from where they stopped (HTTP Range), so repeated short-lived launches still make monotonic progress; a launch that follows an interrupted round skips the startup delay and resumes immediately. HarmonyOS does not need the crash-moment hold: an uncaught JS error does not kill the process there, so the native check completes normally even when JS dies on launch.
 - **It can be turned off**: `disableNativeCheck: true` removes one background request per cold start, at the cost of **giving up the recovery above** — a device bricked by a bad update can no longer heal itself. Choose it only when that request is itself the problem (traffic/battery budgets, privacy manifests, consent-gated networking).
 
 ## Diff Algorithm Comparison