v25 第 25 批（9 条）：名册分组不刷页 / 纪念日多人 / 首页等高 / 移出不回流 /

名册点击看详情拖动才排序 / 任务复选框与状态 / 财务标签多选 / 微信读书同步与统计 /
导航线上数据与图标

用户本轮 9 条需求（原话见 templates/ 与 app/ 内的逐条注释）：

1. 名册：列表里给某人分组改为 AJAX 就地挪卡片（不再整页刷新）。
2. 纪念日：关联人改**多选**（复用 _person_picker，字段 person_ids[]）；
   自建纪念日的按钮与其它模块统一（改=蓝 .btn、删=黄 .btn-warn）；
   列表新增「关联人」列并给人名前加头像。
3. 首页：日程/任务两块**完全等高**（align-items:stretch + 固定总高 + flex 子项
   min-height:0）；修「0 件待办」——数字与右侧列表同源（原来各算各的）。
4. 🔴 名册里被移出的人过一阵又回来：根因是 PersonRoster::seedFromPersons()
   **每次 Schema::ensure() 都无条件重灌**（线上实测每跑一次 +1 行）。
   修：给它加自守卫（只有在 persons 还留着 group_id/sort_order 的**老库**才跑）。
5. 名册：点击=看详情、**只有拖 ⠿ 手柄**才是排序（原来整行既能点又能拖，语义混乱）。
6. 任务：所有任务前加复选框，任何位置点勾即完成；
   状态语义照业界整理为 To Do / Doing / Done 并写出说明（用户要求参考别人的做法）。
7. 财务：类别标签改**多选非互斥**（再点一次取消该类别），上下两图 + 图例 + 表格
   全部按同一个集合联动；高亮条刻意不给「合计」（多选下各类金额不能相加）。
8. 微信读书：新增**懒同步**（访问时顺手做，6h TTL，只补空字段不覆盖用户填的）、
   封面图**拉下来存本站存储**（原来只存外链 → 看不到）、接官方 /readdata/detail 统计。
9. 导航：线上数据只搬了一半（5 板块 29 站 → 7 板块 67 站 + 67 图标）、
   展示页头像不显示 / 搜索按钮错位 / 点登录 404。三个真根因：
   · 相对地址在 /nav/ 下全 404 → 新增 Nav::abs()；
   · 搜索容器丢了 id="search"（CSS 是 #search button.submit 绝对定位）；
   · Nav::iconKey() 与 SimpleNav 的 icon_key() **算法不一致**（少一次 md5 归一化）
     → 搬来的图标文件名对不上；且 uploads/ 整目录 Require all denied。
   新增两个**免登录公开出口** nav_icon.php / nav_avatar.php。

顺带修掉一个「数据损坏级」的真 bug（做第 4 条线上反证时发现的，之前一直没人注意）：
app/Region.php 三处用中文标点当 trim/ltrim 的 charlist，而 PHP 的 charlist 是
**按字节**匹配的 —— 「。」= E3 80 **82** → 字节 82 进了可剥集合 →
「层」= E5 B1 **82** 被切掉尾字节 → 非法 UTF-8 → backfillAddress 的 UPDATE 报
`1366 Incorrect string value` → **地址拆分升级从上线起一直在失败被跳过**（每请求报一次）。
改成字符级 preg_replace('/…/u')；线上实测 ensure() 现在无报错、待拆行数真的在下降。

验证战绩：
- e2e 1289/0（新增 Region 字节级用例等）
- 真机探针：选人 19/0 · 首页/导航 24/0 · 导航模块 34/0 · b18 暂存+确定 10/0 ·
  第23批 52/0
- 桌面几何 428/0 · 移动端几何 680/0 · 交互 92/0 · 窄屏 24/0
- 老库升级 153/0（含 anniversary_people 迁移 + 「再跑 ensure() 名册行数不变」）
- 部署静态断言 180 OK / 0 FAIL · 反向验证 3/3 + Region 三变体各被两条断言同时抓住
- 线上 26 个文件与本地**逐字节一致**；展示页 200、图标 66/66 200、登录 200、
  越权/不存在均 404、签发短语后 ensure() 不再报错。

app/PersonRoster.php

@@ -325,12 +325,40 @@ final class PersonRoster
      * 老库里的 group_id / sort_order 也一并搬——分类语义从"人的属性"变成"我和他的关系"，
      * 但**落在每个人名册里的值不变**，所以看起来完全一样。
      *
+     * 🔴🔴 **自守卫：只在"还没迁移过"的库上跑**（v24 第 25 批 用户第 4 条修的真 bug）。
+     *
+     * 用户原话：「名册中，有一些人，我从名册中移出去了，结果过一段时间就又回来了，
+     *            不知道什么原因，需要查一下。」
+     *
+     * 根因就在这里：本方法原先是**无条件跑**的，而它在**每一次** `Schema::ensure()` 里
+     * 都被调用一次 —— `ensure()` 的触发判据是「Schema.php 源码指纹变了」（见
+     * Schema::fingerprint 的说明），也就是说**任何一次改 Schema 的部署之后，
+     * 所有已迁移完成的老库都会再被重灌一遍全家的成员**。
+     * 于是用户「从我的名册移走」的那个人，在一段时间后（下一次部署 / 下一次改结构）
+     * **自己回来了** —— 而且因为 INSERT IGNORE 只看唯一键，回来的那条 source 还是
+     * 'seeded'，看不出是刚被重灌的。
+     *
+     * ⚠️ 线上实测证据（2026-10-07）：线上运行一次本方法的**前后对比**是
+     *    `total 1621 → 1622`（真的又插回来一条），而此前 members=811、
+     *    名册总行数 1621 > 811×2 —— 差值正是历次重灌留下的。
+     *
+     * 修法：**判据用"persons 上那两个旧列还在不在"** ——
+     *    `group_id` / `sort_order` 是 **v5 迁移的输入**，迁移一跑完它们就被
+     *    `dropColumnIfExists` 删掉了（见 Schema::ensure 里紧跟着的两行）。
+     *    所以「两列都不在」= 这个库早就迁移过了 = 本方法无事可做。
+     *    这样它天然只在**真正需要它的那一次**（老库首次升级）生效，
+     *    不需要任何哨兵键，也不会因为"下次改 Schema"再跑一遍。
+     *
      * 幂等：靠 uk_roster_owner_person 唯一键 + INSERT IGNORE，重复跑不会插重。
      */
     public static function seedFromPersons(\PDO $db): void
     {
         $hasGroup  = self::hasColumn($db, 'persons', 'group_id');
         $hasSort   = self::hasColumn($db, 'persons', 'sort_order');
+        // 🔴 自守卫：旧列都没了 = 已经迁移过 = 绝不能重灌（用户移走的人会回来）
+        if (!$hasGroup && !$hasSort) {
+            return;
+        }
         $oldGroup  = $hasGroup ? 'p.group_id' : 'NULL';
         $oldSort   = $hasSort ? 'p.sort_order' : 'p.id';