统计页把「我的结论」与「访客点赞」拆成两块

用户问「数据统计处的推荐地点和踩雷地点只针对站长吗？应该分开，用户的点赞点踩单独做一块」。
他看到的没错：那张卡的**列表全是站长结论**（verdictPlaces = place_votes），访客票只在副标题里
露了个总数（👍 N · 👎 M）——既看不出哪几个地点被顶上去，也容易被当成两者合并的榜。

- 新增 votes.TopVisitorVoted：按访客票数列地点榜。HAVING 只算**至少有一票的那个方向**，
  否则 0 票的地点会把榜塞满；同票数按 visit_count DESC, p.id 排，刷新之间顺序不跳。
  票按坐标键挂，所以 join 回当前数据集的地点才定位得到（与 Tallies/verdictPlaces 同一口径）。
- 「推荐 & 踩雷（我的结论）」只讲站长，副标题只留「推荐 N · 踩雷 M」，标题与列表都改成「我」的口吻。
- 新增「访客点赞」卡：副标题总票数，两列列 👍/👎 票最多的地点并带票数，各有空态。
- 加载拆成两个 pageJob（verdicts / visitorvotes）并行，两块互不依赖就不该串着等。
- 两块共用同一个可见性开关（IsAdmin || Settings.MarksPublic），与地点页投票区一致。

用例（stats_votes_split_test.go）按卡片标题切出两段 HTML，断言「我标的地点只出现在站长块、
访客顶的地点只出现在访客块」，并核对两边各自的计数——比单看总数更能证明没串台。

⚠️ 又一次同一个坑：两张票表都按坐标键读、与数据集无关，place_visitor_votes 还没有 user_id、
不随删用户清理 ⇒ 上一轮跑剩的票会被算进来、票数越堆越多。新增 isolateVoteState 按 place_key
清两张表（前置 + cleanup 各一次）。

顺带订正 README：那里还写着站长结论「按 src_pk 存」，其实早就是坐标键了。
全量验收 PASS=338 FAIL=0 SKIP=0。

.workbuddy/memory/2026-10-01.md

@@ -34,3 +34,19 @@
 改成整段排在 `place_images` 建表之后（它是五张里最后一张），并把这个坑写进 schema.sql 的注释里。
 教训：**凡是 ALTER 某个表的迁移块，先确认那张表在文件里已经建过了**——
 只在本机库上跑一遍是测不出来的，必须跑 fresh-database 用例。
+
+## 统计页：站长结论与访客点赞拆成两块（01:40）
+
+用户问「数据统计处的推荐地点和踩雷地点只针对站长吗？应该分开，用户的点赞点踩单独做一块」。
+他看到的没错：那张卡的**列表全是站长结论**，访客票只在副标题露了个总数。
+
+- 新增 `votes.TopVisitorVoted`（`HAVING` 只算至少有一票的方向，否则 0 票地点塞满榜；
+  同票按 `visit_count DESC, p.id` 保证顺序稳定）。
+- 「推荐 & 踩雷（我的结论）」只讲站长；另起一张卡「访客点赞」，列 👍/👎 票最多的地点并带票数。
+- 两个 pageJob 并行加载；两块共用 `IsAdmin || MarksPublic`（与地点页投票区一致）。
+- 用例按卡片标题切 HTML 断言「A 只在站长块、B 只在访客块」，比数总数更能证明没串台。
+
+⚠️ 又踩同一个坑：票表按坐标键跨数据集读、`place_visitor_votes` 还没有 user_id ⇒
+上一轮跑剩的票会被算进来。新增 `isolateVoteState` 按 place_key 清两张表（前置 + cleanup）。
+
+顺带订正 README：那里还写着站长结论「按 src_pk 存」，其实早就是坐标键了。