v33 第 33 批：DAV（Thunderbird）三处真根因修复

用户原话：
  看看 dav 功能，还是不好用，thunderbird 提示这两个地址下没有任何联系人和日程。

关键教训：v31 那个探针（复刻 SyncCalendar 的 DavClient）线上 28/0 全过，
但用户还是空的 —— 因为 Thunderbird 的请求形状不一样：它真正取数据用的是
REPORT（calendar-multiget / addressbook-multiget），而 v31 探针只走
PROPFIND + GET。复刻了 A 客户端全绿，证明不了 B 客户端能看见东西。

三处真根因（都靠新探针 _fb_dav_tb.py 逐步 dump 原始 XML 抓出）：
① CardDAV 的 REPORT 回的是草案名 <card:address-data>，而 RFC 6352 规定是
   <card:addressbook-data>。Thunderbird 要后者 → 拿到 0 个数据块 → 通讯录永远空。
   修：新增 $cardDataXml 闭包，照客户端点名的属性回正文（没点名默认正式名）。
   注：第一版写成两个都发 → 正文重复一份、e2e 的 BEGIN:VCARD 计数翻倍，改成按需回。
② home-set 的 Depth:1 响应里没有集合自身。RFC 4918 要求 PROPFIND 响应必须包含
   被请求的资源本身，原来只在非 home 请求时才输出 → PROPFIND /dav/calendars/
   只回子本、没有自己 → 严格客户端判 home 不存在 → 一本都看不见。
   修：dav.php / carddav.php 的 home 分支始终先输出集合自身。
③ 站点根 PROPFIND / 被 Apache 交给 index.php → 302 跳登录页 → Thunderbird 判定
   这个域名下没有日历（RFC 6764 允许从域名根发现）。
   修：router.php（本地）+ .htaccess / 部署脚本 5c 段独立标记块（线上）：
   RewriteCond 限住 REQUEST_METHOD + RewriteRule ^$ dav.php；
   必须限方法，否则 GET / 被 ^$ 吞掉、首页 404（已加反向守卫）。
   并让根响应与两个 principal 都给出两套 home-set（calendar + addressbook）。

验证：线上真机 _fb_dav_tb.py 25/0（站点根通 / home-set 含自身 / CardDAV REPORT
真带回 3 个数据块，修复前是 0）；逐本 REPORT 所有集合都能取回数据；
旧诊断（SyncCalendar 序列）28/0 无回归；GET / 仍是 302 未被吞。
本地 e2e 1503/0、v33 DAV 反向验证 7/0（三处各自改回旧行为 → 断言全变红）；
部署脚本静态断言段本地空跑通过。

.htaccess

@@ -28,6 +28,16 @@
 RewriteRule ^\.well-known/caldav$ dav.php [L,QSA]
 RewriteRule ^\.well-known/carddav$ carddav.php [L,QSA]
 
+# 🔴 v33：站点根的 **DAV 方法**也交给 dav.php（RFC 6764 允许从域名根发现）。
+#    病根：`PROPFIND /` 被交给 index.php → 302 跳登录页 → Thunderbird 判定
+#    "这个域名下没有日历"，用户报的就是「提示没有任何联系人和日程」。
+#    ⚠️ 必须用 `RewriteCond` 限住 **REQUEST_METHOD**：不加的话 `GET /` 也会被吞掉、
+#       站点首页直接 404。只放行 PROPFIND/REPORT/OPTIONS 三种 DAV 方法。
+#    ⚠️ 这条要排在下面 `^dav` / `^carddav` **之前**（空 Pattern 匹配的是根，
+#       与那两条前缀互不包含，但先写更清楚）。
+RewriteCond %{REQUEST_METHOD} ^(PROPFIND|REPORT|OPTIONS)$ [NC]
+RewriteRule ^$ dav.php [L,QSA]
+
 # CalDAV：/dav/、/dav/3.ics/、/dav/3.ics/12.ics 全部交给 dav.php
   RewriteRule ^dav(/.*)?$ dav.php [L,QSA]