背景:生产此前**完全统计不了 PV/UV** —— 前端无任何分析埋点(gtag/umami/plausible
全无),服务端无 request log,生产 ECS 上更没有 nginx(pac.friday.tech 走独立网关
lb1.friday.tech,访问日志不在我们这台机器上)。Sentry 只有 10% tracing 采样,
做 UV 会系统性偏低。

范围限定在 plan 详情页(切合 plan_event_logs 表名):plan_id / patient_id 本就是
该表的必填列,浏览事件天然填得上,不必为它放宽约束或另立新表。

三种入口按用户口径**全收**:直接进/刷新 · 患者列表 rail 切换 · /plans 落地自动跳转。
(自动跳转确实是系统行为,但业务侧确认要收 —— 它也代表这条 plan 被展示过。)

⭐ 唯一的雷:byHuman 不是"是不是人做的",是**口径开关**
  HUMAN_TOUCH_EVENTS 靠 filter(byHuman) 派生。view 按字面语义该写 true,但那会让
  「客服处理过哪些患者」静默膨胀成"看一眼也算处理"——刚交付的 65 人统计与整张
  客服明细 Excel 全部失真,**而且不会有任何编译错误或类型报错**。
  故 view 写 byHuman:false,并把该字段注释从"是否人工动作"改写成明确的口径定义;
  spec 里用**精确相等**(非 arrayContaining)锁死 HUMAN_TOUCH_EVENTS 的四个成员,
  以后新增事件必须显式决策要不要计入,改错即红。

改动:
- enums: PlanEventType.VIEW + PLAN_EVENT_META 项(group 联合类型扩 'view')
- controller: POST /pac/v1/plans/:id/view。**刻意不加认领闸**(区别于 recall-feedback)——
  浏览发生在认领之前,池子里任何一条都能点开;加闸则埋点只剩已认领的,PV/UV 直接废掉。
  plan 不存在静默返回 not_found:埋点是旁路,不能因它失败而影响页面。
- 前端: 埋点挂在 use-plan-aggregate 现成的去重守卫里 —— 该守卫原为防 StrictMode 双调,
  其语义恰好等于"每进入一次详情页";refresh() 直接调 load() 走不到这里,故手动刷新不重复计。
  失败 .catch(()=>{}) 吞掉。

验证(本地起真实前后端 + 浏览器实操):
  /plans 自动跳转 → 记 1 条 ✓    手动点刷新 → 仍 1 条(不重复计)✓
  重新进入页面   → 累计 2 条 ✓    未认领查看 → 能记 ✓
  plan 不存在 → not_found 不报错 ✓  无 token → 401 ✓
  ⭐ 只有 view 事件的患者,在「处理过」口径下计 0(全事件口径会误计 2)✓
  640 tests passed,service/web typecheck 通过。

无 DB 迁移(event 是既有 text 列,加的是取值不是列)。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>