laoyang
b32501535e
日程改为全量同步 + 修复大响应超时（laoyang/FamilyBook#31）
## 背景
用户 2026-10-30：「全部拉取，全量同步」。
起因：切到下个月再点某一天，端上没数据（即使服务端有）。
根因是请求范围写死成「今天-7 ~ +60」且切月不重拉 ⇒ 窗口外的日子永远空。
## 改动
### FbModuleLoad.loadModule
- `name` 参数从 `FbModuleName` 放宽到 `string`
日程改成全量后，缓存键要带请求窗口（`calendar:1970-01-01:2100-12-31`），
否则"旧窗口的数据"会被当成新窗口的数据显示。
- 新增可选 `timeoutMs`
全量约 9.3MB / 28628 条，默认 15 秒在移动网络下会超时；
超时后 `FbModuleRepo` 退回旧缓存，表现成"翻月没数据"且极难查。
### FbModuleRepo.load
- 透传 `timeoutMs` 给 `FbApi`。
### FbCalendarPage
- 请求改为全量范围（`CAL_FULL_FROM` ~ `CAL_FULL_TO`），超时放宽到 60 秒。
- 缓存键带窗口（`calendar:<from>:<to>`）：某次请求失败后 `FbModuleRepo`
会把**旧范围**的缓存 sink 回来，端上就把"只含 10~12 月的数据"当全量显示
—— 这是该 bug 的帮凶，加窗口标识后从根上消失。
- `agendaDays()` 的 `-7 ~ +60` 现在**只决定列表显示多少天**，
不再兼作请求范围（原来两个数必须同步的约束随全量同步作废）。
- 删除 `agendaFrom()` / `agendaTo()`（不再需要按当前日期算窗口）。
### 恢复 canEdit 的写权限判断
本轮改动曾把
`isEventWritable(this.detailBase, this.books)`
回退成
`isEditableEvent(this.detailBase)`
这是**工单 #31 已修过的 bug 回退**：只判 kind/id/calId 不看本的可写性，
导致只读共享日历里的日程也显示「编辑」按钮，用户改完点保存才报
「这本日历你没有写权限」。
已恢复，并与首页 `FbHomePage.ets:1517` 保持同一口径
（否则同一事件"从首页进能编辑、从日历页进不能"）。
## 验证
`build_hap debug` → `BUILD SUCCESSFUL`（33 tasks）。
⚠️ **未做真机验证**。全量同步的实际耗时与内存占用需在真机上确认
（28628 条约 9.3MB，解析 150~300ms，主要成本是流量）。
## 备注
这 3 个文件的改动来自 2026-10-30 那一轮，因故未提交；
本次一并整理提交，与品牌改名（家书→岁月家）无关。
2026-11-01 22:54:22 +08:00
..
2026-11-01 22:54:22 +08:00
2026-10-11 22:07:48 +08:00
2026-10-11 22:07:48 +08:00
2026-10-11 22:07:48 +08:00
2026-10-11 22:07:48 +08:00