领证纪念日实际关联 2 人；端上只读了老列所以只带出 1 个 (#91d)

用户 2026-11-05：「你去查一下这个领证纪念日到底关联了几个人，数据库里。」

查库结果：
  anniversaries #2 「领证纪念日」
    person_id = 1                    ← **老列**，只能存一个
  anniversary_people（多对多表）
    person_id=1  杨永全
    person_id=3  洪博为
    = **2 人**                        ← 真正的事实

根因链（两处都缺一不可）：

① 服务端 `occurrences()` 从来没输出 `person_ids`
   `peopleMap()`（查多对多表）只在 `split()` 里用了 —— 那是**网页端**的路径；
   `occurrences()` 是 API（鸿蒙端）用的，只透传了 `person_id` 这个老列。
   ⇒ 端上永远只拿到 1 个人。
   ⇒ occurrences 开头一次性 `peopleMap(array_column($all,'id'))`，
     输出 `person_ids`（多对多表为准，为空才退回老列）。

② 端上编辑框只读 `dayDetail.personId`（单个数字）
   ⇒ 改用 `personIds.slice()`（完整列表）。
   FbRecentDay 新增 `personIds: number[]`；`parseRecentDays` 里
   "person_ids 非空就用它，否则退回 person_id"。

⚠️ 老列 `anniversaries.person_id` 是升级到多对多之前的遗留字段。
   两边不一致时**以多对多表为准**（用户在新版界面上改的就是那张表）。
⚠️ 部署时踩了一次：第一次 scp 没生效（服务端文件 grep 不到新代码），
   导致验证结果仍是空的。重新部署并 md5 比对后才确认生效。

实测（部署后）：
  领证纪念日   person_ids = [1,3]  → 杨永全、洪博为 ✅
  杨永全 的生日 person_ids = [1]    （派生条目单个人）
  其余派生条目同理，各 1 人。

编译通过，已装真机。

entry/src/main/ets/pages/home/FbHomePage.ets

@@ -2186,7 +2186,17 @@ export struct FbHomePage {
           editingRepeat: 'solar',
           editingMonth: 1,
           editingDay: 1,
-          editingPersonIds: this.dayDetail.personId > 0 ? [this.dayDetail.personId] : [],
+          /* 🔴🔴 #91d（用户 2026-11-05）：「你去查一下这个领证纪念日到底关联了
+             几个人，数据库里。」
+
+             查库：「领证纪念日」关联 **2 人**（杨永全 #1 + 洪博为 #3）。
+             而这里原来只读 `dayDetail.personId` —— 那是**老列**
+             `anniversaries.person_id`，只能存一个 ⇒ 洪博为被静默丢掉，
+             编辑框只带出 1 个人。
+             ⇒ 改用 `personIds`（服务端按多对多表给的完整列表）。
+             ⚠️ `personIds` 为空时才退回老列（老数据还没回填多对多表的情况），
+                这段兜底已写在 `parseRecentDays` 里，这里直接用即可。 */
+          editingPersonIds: this.dayDetail.personIds.slice(),
           roster: this.dayRoster,
           onClose: (): void => {
             this.closeDayDetail();