微前端子应用「静默崩溃」：ErrorBoundary 兜住不白屏，但 RUM 零异常、用户侧功能缺失，怎么把"静默失败"变成可观测信号？

【背景】 做了 15 年前端，最近在一个 B 端运营中台（宿主 Shell + 5 个子应用，qiankun 2.x，各子应用 React 18 独立发版）碰了一个很典型的"监控盲区"：错误监控全线绿，但用户侧有功能悄悄丢了。

架构约定：每个子应用外层套 ErrorBoundary，任何子应用内部异常（含 render 抛错、第三方 SDK 注入脚本抛错）都被兜住，宿主展示"模块加载失败 + 重试"的兜底 UI，主框架其他模块不受影响。这个设计本身是对的——我们宁可局部降级也不整页白屏。

【现象（卡点）】

1. RUM 侧零异常：Sentry 里子应用错误计数正常（ErrorBoundary componentDidCatch 里手动 captureException 了），但 RUM 的 Core Web Vitals、页面可用性、错误率看板全绿——因为"页面没白屏、LCP 正常、没有 unhandledrejection"，在绝大多数 RUM 口径里这算"一次成功访问"。
2. 用户侧功能缺失：数据看板子应用里"导出报表"按钮整个消失（该组件子树被 ErrorBoundary 吞掉），运营同学反馈"功能没了"，工单到我们这已经过了一整天，而监控上什么都没有。
3. 归因困难：ErrorBoundary 兜住的信息是"某个子树挂了"，但兜底 UI 是通用的——不知道是哪个业务功能缺失、缺失影响了多少用户、持续多久，也没有"降级中"的持续状态信号（用户点重试成功一次后，状态就归零了）。

【已尝试与结果】

• ① 在 componentDidCatch 里 captureException 并带上子应用名 + 路由：解决了"错误有没有发生"，但没解决"哪些用户处于降级态"——错误是一次性的，降级是持续的。
• ② 给兜底 UI 打 RUM 事件（custom event: degraded_module）：能数出"多少人看到兜底 UI"，但口径是"看到"而不是"功能缺失"，且宿主和子应用各报一次会重复计数，跨子应用聚合也没有统一维度。
• ③ 宿主侧轮询子应用健康心跳（每 30s ping 子应用 window）：能发现"子应用挂了"，但粒度到不了"哪个功能没了"，而且 ping 本身有 false negative（子应用主线程被长任务卡住时 ping 也超时，但其实是卡顿不是崩溃）。

【期望得到的答案形态】

1. 有没有把"ErrorBoundary 兜住"建模为持续状态（degraded 状态机：ok → degraded → recovered，带持续时长）并上报到 RUM 的成熟做法？具体事件 schema 长什么样、采样怎么定？
2. "功能级缺失"的可观测性怎么落地——是子应用声明"关键功能清单"（feature manifest），宿主/SDK 检查每个 feature 的挂载节点是否存活，还是别的思路？落地成本大概多少人天？
3. 告警口径：degraded 用户占比的阈值你们怎么定的？和后端 error rate 的口径怎么对齐（参考 #1490 里降级深度定 SLO 的讨论，但那是 B 端数据页缓存降级，我的场景是渲染崩溃降级，两者的"降级深度"分级能不能复用一套模型）？
4. 有踩过"ErrorBoundary 兜底 UI 本身也崩"（兜底的兜底）的坑吗？宿主侧的最后一道防线你们怎么做的？

想收集不同团队（qiankun / micro-app / wujie / 自研沙箱）在这个问题上的实际做法，以及"功能缺失可观测"这件事的真实投入产出比——如果收益撑不起成本，你们是怎么取舍的。