SPA 内部路由切换不触发 navigation：TTFB/FCP 对"路由跳转"完全失明，怎么在 RUM 里给每次路由切换打"用户感知级"观测？

背景 React 18 + Vite 5 的 B 端中台 SPA，约 220 个路由，自研 RUM SDK 用 PerformanceObserver 采 Core Web Vitals（LCP/CLS/INP）+ performance.getEntriesByType('navigation') 取 TTFB/FCP，采样 100%，日均 UV 约 12 万，落 ClickHouse 出大盘。我们的核心交互是用户点菜单从 A 路由跳到 B 路由（history.pushState，不整页 reload）。

现象（这是真正的卡点）

• PerformanceNavigationTiming 的 navigationStart 始终是首次加载那一刻。用户从 A 跳到 B，B 路由的 TTFB/FCP 读到的还是首页的数字，对"这次路由切换花了多久"完全失明。
• LCP 也只反映首屏最大元素，B 路由里那个 4.2s 才渲染完的图表列表不进 LCP。
• 我手动 performance.mark('route-start') / mark('route-ready') + measure 只能拿到一个裸 ms 数字（比如 A→B 平均 3.8s、P95 6.1s），但拿不到 TTFB/FCP/INP 这种"用户感知"维度，也没法和 Web Vitals 大盘对齐、没法算分位、没法设阈值告警。
• 结果：首页加载性能我盯得很细（见我另一个 LCP 告警的问题），但用户每天点几十次的"路由切换"反而成了观测盲区——用户抱怨"切个页面卡"，我这边没有一条数据能定位到是哪个路由、卡在接口还是渲染。

已尝试的排查

1. PerformanceObserver 监听 resource entry 等接口：能拿到接口耗时，但无法区分"路由切换触发的请求"和"页内组件懒加载的请求"，同一时刻混在一起，归因不了；
2. mark/measure 手动打点：只有裸 ms，缺 TTFB/FCP 语义，且不同路由"ready"的定义不统一（有的等接口、有的等首帧、有的等交互）；
3. 试过让路由切换走整页 reload 来"骗"出新的 navigation timing：体验差（白屏 + 丢前端状态），产品不接受；
4. 用 INP 兜"交互慢"：INP 是全局的，定位不到"哪次路由切换慢"。

期望得到的答案形态

• 具体怎么做"路由级（route-level）性能观测"：用哪些 API / 钩子（PerformanceObserver 的哪类 entry？History API 拦截？React Router 的 useBlocker/useNavigation？自定义"伪 navigation"？），以及"路由切换的可交互完成"到底该怎么定义、卡在哪个里程碑打点；
• 怎么把这次观测落到 RUM 大盘：字段怎么设计（比如 route_from/route_to/route_ttfb/route_fcp/route_ready）、和 Web Vitals 怎么对齐、分位怎么算；
• 阈值 / 告警怎么定（带数字：多少 ms 算慢、观察窗口多长）；
• 最好能贴可复现的代码片段（采集端 + 大盘字段），我直接对照改我们的 SDK；
• 如果你踩过"接口耗时 vs 渲染耗时"归因的坑，请标注你们的路由量级和切换耗时分布，方便我对照。