Add SLO telemetry for message ordering and consistency

[ULookup]

Target Version

3.0-dev。复核基于 origin/3.0-dev 提交 a75fc8721b99e5c0b4421d0c58b5618bbe71ff31（PR #57）。缓存/Redis/Push 已新增局部计数器，但消息端到端可靠性 SLO 仍不可计算。

Evidence

• common/infra/metrics.hpp:14-34 现已暴露 L1/L2 hit/miss、成员快照竞争、Redis breaker、Redis 调用失败、本地限流、Push unacked 持久化失败和消息 requeue 计数。
• RL-05 与 PF-09 已使用部分 bvar 证明 Redis 故障恢复和缓存状态，说明指标契约可以被测试驱动。
• 仍缺少 accepted/broker-confirmed/persisted/fan-out/delivered/acked 阶段漏斗与端到端延迟。
• 仍缺少 RabbitMQ ready/unacked/oldest age、retry/DLX、MySQL Outbox age、seq regression/fence、unacked oldest age 与 membership repair backlog。
• scripts/prometheus/ 没有消息可靠性 dashboard/alert/runbook 契约；现有局部 counter 也没有统一低基数标签、SLO 分母和窗口定义。
• PR feat(cache): harden Redis resilience and multilevel caching #57 CI 上游构建失败，Reliability/Perf cache job 被跳过，尚未形成可持续的指标 gate 证据。

Problem or Goal

在保留 PR #57 局部指标的基础上，建立可操作的消息可靠性与一致性 SLI/SLO，使丢失风险、重复、乱序、积压、降级与恢复时间能按阶段检测和告警。

Scope

• 定义 accepted、broker-confirmed、persisted、fan-out、delivered、delivery-acked 阶段指标与延迟。
• 补齐 consumer lag/age、retry/DLX、Outbox、unacked、seq fence、幂等冲突与 cache repair 指标。
• 统一低基数标签、匿名关联、dashboard、告警、runbook 与采样/保留策略。
• 定义 availability、durability、ordering、delivery latency、convergence 的 SLI/SLO。
• 在 Functional、Reliability 与 Performance 中验证指标 firing/recovery 和状态收敛。

Non-goals

• 不在本 Issue 修复指标暴露的生产缺陷。
• 不把日志条数当作 SLO 分母。
• 不以 user/conversation/message ID 作为 Prometheus label。
• 不强制选定商业监控平台。

Acceptance Criteria

• 可计算发送确认到持久化、持久化到 Push、Push 到 ACK 的成功率与 P50/P95/P99。
• 可观察每个 consumer 的 ready/unacked、oldest age、retry、DLX 与耗时。
• 可观察 MySQL/Redis Outbox、unacked 与 membership repair 的 pending 数和最老年龄。
• seq regression/fence、幂等命中和唯一键冲突有独立计数。
• 现有 breaker/cache/push counter 纳入统一命名、标签与 SLO 说明。
• 所有 label 通过基数和敏感数据审查。
• dashboard/alerts 能定位阶段、服务、依赖与 runbook，并有 firing/recovery 测试。
• SLO 文档定义分母、窗口、缺失数据、维护窗口和 error budget。

Test-first Plan

先增加 TestMessageReliabilityMetricsContract，驱动完整发送、持久化、Push、ACK 及依赖故障，运行：

cd tests && go test -tags=func ./func/... -run TestMessageReliabilityMetricsContract -v -count=1

预期 RED 是业务成功/失败后阶段指标缺失或不变化。最小 GREEN 先补核心阶段漏斗和 lag，再加入 Reliability firing/recovery、Performance 开销与 agent-policy 文档契约。

Risk and Security

高基数、过多 bucket 或同步打点会损害性能。指标与 trace 不得泄露用户、消息、token 或 secret；阈值必须由容量基线校准，避免告警风暴。

Architecture Impact

No。复用现有 bvar/Prometheus 边界，不改变服务职责或真相源。

Core-flow Impact

No。只观测业务阶段，不改变成功、重试、顺序或 ACK 语义。

Required Skill Updates

• 更新 technology stack，登记完整消息 SLI/SLO 与采集入口。
• 更新 testing case catalog，登记指标 Functional/Performance/Reliability 用例。
• 更新 canonical monitoring 文档、dashboard、alerts 与 runbook。
• 如 core flows 列举可观测阶段，同步更新该引用。