v0.8.0 本地加密 / 被踢清数据 / 增量同步 / 附件队列 / 顶栏同步进度

用户 2026-10-18 两条：
「直接做 L3 锁界面 + 本地加密（HUKS，踢设备即吊销密钥）：数据在但读不出，
  重登后恢复密钥即可用。」
「右上角头像和提醒前面加同步进度…首次全量、之后增量；进来先展示本地数据，
  一边同步一边更新；附件后台队列同步（名册头像 / 电影海报 / 观影照片 / 资源附件）。」

① 整库加密（FbSchema v4→v5，新增 module_sync / attach_cache 两张表）
   RDB encrypt=true。加密属性一经创建不可修改 ⇒ openWithEncryption 三段式：
   直接开 → 失败删库重建 → 再失败降级明文（degraded 字段，设置页如实显示，
   不静默降级）。

② 两层密钥（FbKeyStore）
   HUKS 里 KEK（fb_kek_v1，不可导出）包裹 32 字节 DEK；revoke() 删 KEK
   ⇒ 已落盘附件密文在数学上解不开，这就是"踢设备即吊销密钥"。
   重新登录重新生成 DEK 并重下附件（不做服务端托管，为了省一次重下
   把能解你本地数据的密钥放到服务端不值）。
   会话属性里 PURPOSE 只出现一次：原来把含 ENCRYPT|DECRYPT 的生成属性直接
   拿去开会话再 push 一个 PURPOSE，同一 tag 出现两次在 HUKS 里行为未定义
   ⇒ 拆成 kekBaseProps / kekGenProps / kekSessionProps。

③ AES-256-GCM（FbCrypto）
   落盘 iv(12)|ct|tag(16)；变换串必须带 padding 段（AES256|GCM|PKCS7，
   缺了抛 801）；解密从尾部切 tag。

④ 附件后台队列（FbAttachQueue）
   attach_cache 台账（pending/done/fail，MAX_TRIES=3）；密文放 filesDir、
   明文临时放 cacheDir；扩展名白名单筛 key。
   图片地址收成统一入口 fbImageSrc(key,token)：本地有就用 file://，
   没有才回网络 —— 收成一个函数才漏不掉（5 个页面全部改过来）。

⑤ 被踢 / 退出清数据
   lockOut → 清令牌 → FB_ATTACH.wipe（第一步就是吊销 KEK）→ FbDb.wipe
   （先关句柄再 deleteRdbStore，并发去重，open 会等它）→ 同步状态复位。
   重新登录后重建密钥 + 库 + 附件索引，否则之后只读网络不写缓存且不报错。

⑥ 增量同步（FbSyncAll 重写）
   先问 /api/v1/changes；指纹相同就跳过。本地没水位必须拉（否则老用户升级后
   一个模块都不同步）；24h 陈旧上限兜"改无 updated_at 表的已有行"；
   /changes 拿不到时判 ping status>0 —— 断网直接收工，不退回全量
   （否则 12 个模块各等 15 秒）。
   家谱也进了预同步列表（原来只在打开时拉，离线是一片空白）；
   总步数由 CACHE_MODULES.length 算出，不写死。

⑦ 删除传播
   服务端是物理删除、没有墓碑 ⇒ 观影同步改成"先清后插"
   （persons 跨模块共用，不清）。

⑧ 顶栏同步进度
   头像与铃铛之间加三态按钮（转圈 / 红感叹号 / 灰对勾）+ bindSheet 面板：
   进度条、「N 个模块没有变化」、附件行、失败清单、立即同步（防连点）。
   状态中心 FbSyncState（@ObservedV2 + @Trace，AppStorageV2 单例）；
   界面直接读 @Trace 字段，不提供派生 getter。

验证：hvigor BUILD SUCCESSFUL；_fb_arkts_guard.js 290/0（本批新增 59 条）；
_fb_v58_falsify.py 31 项注入 38/0；b57 反向验证 12/0（锚点跟上本批 logout 改动）；
本地 e2e 1519/0；全量流水线 PUSH_RC=0。

entry/src/main/ets/data/FbMovieRepo.ets

@@ -264,6 +264,26 @@ export class FbMovieRepo {
       ' / 人 ' + personRows.length.toString() +
       ' / 同看 ' + attendeeRows.length.toString() + '）…';
     const store: relationalStore.RdbStore = this.db.require();
+
+    /* 🔴 v59：先清掉上一次的观影数据，再整批写入 —— 这是**删除传播**的实现。
+     *
+     *    之前只做 upsert（`INSERT OR REPLACE`），于是"在网页上删掉的那一场电影"
+     *    在端上永远留着 —— 用户看到的是已经不存在的记录，还以为同步坏了。
+     *    服务端是**物理删除**（没有 `deleted_at`），所以没有墓碑可拉，
+     *    客户端唯一可靠的判断方式就是"这次没返回 = 已被删"。
+     *
+     * ⚠️ 为什么敢在"拉取成功之后、写入之前"清：
+     *    上面所有失败分支都已经 `return` 了 —— 走到这里说明**服务端数据完整到手**。
+     *    拉取失败时绝不会清，用户手上那份旧数据仍然可用。
+     * ⚠️ 为什么不清 `persons`：它是跨模块共用表（名册/观影都写），
+     *    清它等于把名册也清了。观影同看人残留几条无害（名册同步会覆盖）。
+     * ⚠️ 清 `events` 只清 `kind='movie'`：日程模块将来写入的条目不能被观影同步顺手删掉。
+     */
+    await this.db.exec("DELETE FROM events WHERE kind = 'movie'");
+    await this.db.exec('DELETE FROM movie_details');
+    await this.db.exec('DELETE FROM event_attendees');
+    await this.db.exec('DELETE FROM cinemas');
+
     await this.insertInBatches(store, 'cinemas', cinemaRows);
     // ⚠️ 顺序：events 是主表，其余引用它的 id（便于排查，非外键强制）
     await this.insertInBatches(store, 'events', eventRows);