日历本默认名：旅行 → 旅程 (#71)

用户 2026-11-05：「旅程的日历本同步到日历本，它的日历本名字就叫"旅程"，
观影就叫"观影"。我看现在"旅程"叫"旅行"，这个不对，应该改过来。」

代码只改一处：app/Calendar.php 的 DEFAULT_BOOKS 常量
  trip => [旅行, ...] → [旅程, ...]

这段只影响**新家庭首次 seed**。已建好的家庭数据在库里，改常量不回溯
⇒ 另外跑了 UPDATE calendars SET name=旅程 WHERE kind=trip AND name=旅行
  （按值匹配，不无脑按 kind 覆盖：万一用户自己改过名，不该把他改的抹掉。
   虽然 trip 本在代码里是禁止改名的派生本，但按值匹配总是更稳）
实测改了 2 行（历史上 seedDefaults 重复跑过，有两套）。

movie 那条**没动** —— 用户明确说"观影就叫观影"，本来是对的。

顺带把文件头注释里的「旅行」也改成「旅程」，
否则注释说"名字就叫观影、旅行"，代码里却是"旅程"，后人又要被误导。

实测：
  Calendar::mine() → #1 [观影] kind=movie
                     #2 [旅程] kind=trip
  行程条目 calname = [旅程] ✓
  观影条目 calname = [观影] ✓

app/Calendar.php

@@ -4,12 +4,12 @@
  *
  * 三条核心设计（用户 2026-10-01 第 7 条逐条对应）：
  *   ① **每人可建日历本**（自定义名字 + 自定义颜色），并能共享给别人（只读 / 可写）。
- *   ② **观影与旅行是每人默认的两本**，名字就叫「观影」「旅行」，内容**从 events 派生** ——
+ *   ② **观影与旅程是每人默认的两本**，名字就叫「观影」「旅程」，内容**从 events 派生** ——
  *      不复制一份进 calendar_events，否则"改了观影记录、日历还是旧的"。
  *      反过来，在日历里给观影本新增日程 = 写一条 events(kind='movie')（真的成为一条观影记录）。
  *   ③ **没有具体时分的日程 = 全天日程**（all_day=1）。
  *
- * 日历其实是"综合视图"：自定义日程 + 观影 + 旅行 + 有截止时间的任务，
+ * 日历其实是"综合视图"：自定义日程 + 观影 + 旅程 + 有截止时间的任务，
  * 各模块各自出数据，日历只负责按日期摆出来（见 Calendar::month()）。
  */
 
@@ -49,7 +49,15 @@ final class Calendar
               custom 排最前，所以它天然就是"新建日程"的默认本。 */
         'custom'  => ['我的日程', '#4A7C82'],
         'movie'   => ['观影', '#7A4E8C'],
-        'trip'    => ['旅行', '#3F7D5A'],
+        /* 🔴 #71（用户 2026-11-05）：「旅程的日历本同步到日历本，它的日历本名字
+           就叫"旅程"，观影就叫"观影"。我看现在"旅程"叫"旅行"，这个不对，应该改过来。」
+
+           ⇒ 「旅行」→「旅程」。模块本身一直叫"旅程"（页面/菜单/接口全是旅程），
+              只有这本默认日历的名字是"旅行" —— 用户进日历看到"旅行"会觉得是另一个东西。
+           ⚠️ 改这里只影响**新家庭首次 seed**；已有家庭的库里数据要单独 UPDATE
+              （见同批部署的 SQL）。
+           ⚠️ `movie` 那条**不要动** —— 用户明确说"观影就叫观影"，本来就是对的。 */
+        'trip'    => ['旅程', '#3F7D5A'],
         'lunar'   => ['农历', '#8C6D3F'],
         'holiday' => ['节假日', '#B0342C'],
         // v24 第 12 批 #4（用户原话：「增加系统日历本，一个是传统节日…再增加一个