laoyang
f807a5d99f
fix(同步): Inbox 待办同步已恢复正常，撤销上一轮的误判 (#54)
## 重要更正
上一轮（#53）我判断"群晖把 home_todo 当 home 别名"是**错的**。
原因：我当时在 App 里建的那条待办卡在未同步状态，误导了判断。
## 真实情况（本轮实测）
用户在电脑端 Inbox 新建一条「测试收件箱」待办后：
```
日历本[1]「Inbox」待办：REPORT 1 个资源，解析 1 条，新增1 更新0 删除0 不变0
```
本地库确认：
```
748 | _1 | event | Hvf | syncal-*.ics ← 旧脏数据
755 | _1 | todo | 测试收件箱 | 20261105T121432-*.ics ← 新建待办，已正确入库
```
**Inbox 的 VTODO 同步是正常的。** 之前查到空 multistatus，
是因为 App 内创建的那条在服务器上尚未落定（Put 201 但 REPORT 未立即可见）。
## 真正修好的是 #51 的问题
纯待办本跳过 event 通道（#51）防止了 Hvf 这类脏数据继续产生：
```
日历本[1]「Inbox」是纯待办本(COMP_SET=todo)，跳过 event 通道
```
## 本次改动
- 移除临时 PROPFIND 诊断分支
- 保留 `listNames()` 工具方法（后续排查服务器文件清单可用）
- 保留 `reportRaw()` / `reportAll()`（通用 REPORT 能力）
## 编译
BUILD SUCCESSFUL
## 遗留
本地库 id=748（title=Hvf, kind=event, cal_key=_1）是修复前产生的脏数据，
待清理（不影响使用，但会占用 Inbox 本的一行）。
2026-11-05 12:17:38 +08:00
..
2026-11-05 12:17:38 +08:00
2026-09-13 15:50:37 +08:00
2026-09-13 15:50:37 +08:00
2026-09-13 15:50:37 +08:00
2026-09-13 15:50:37 +08:00