feat: bmw同步SurrealDBBinding路由到Redis --story=133245352

[Zhaoyikaiii]

变更

• 在 BMW 空间路由任务中增加 SurrealDBBinding 路由同步，写入 bkmonitorv3:spaces:surrealdb_binding。
• 从 BKBase Resource API 读取 bkm_data_link_strategy=graph_relation_time_series 的 SurrealDBBinding，提取 database、namespace、binding 名称、集群名和 phase。

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c4b8baf605

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chenguo367]

Owner 复核（基于 head 13f4627）

核心逻辑正确、与消费侧 v1beta3（#1282）schema 对齐、BKBase 不可用时降级安全（保留旧路由）。无代码级硬阻塞。以下为建议项，其中前两条建议合入前处理：

⚠️ 建议合入前处理

1. 空结果误清路由（最需关注）
ListSurrealDBBindings 返回 error 时正确跳过清理、保留旧路由；但若 BKBase 返回 200 且 data 为空（如 label 索引短暂未就绪 / 后端抖动），PushSurrealDBBindingDetails(tenant, [], ...) 会走到 clearStaleSurrealDBBindingDetails，把该租户全部 field 删除。消费侧是 TTL 缓存，缓存过期后该租户图查询将进入空窗，直到下一轮同步恢复。

• 失败场景：BKBase 成功但空 → 在线路由被清 → 图查询空窗（约一个缓存 TTL）。
• 建议：对「本次结果为空、但 Redis 中该租户原有路由」的情况加 sanity check（显式区分"确认无 binding"与"疑似异常空"，后者打 Warn/加指标、不清理或延迟清理）。

2. 生产/消费依赖两套不同开关信号，须联合上线 + 逐环境核对

• 生产侧 field 后缀由配置 EnableMultiTenantMode 决定（ON→bkcc__<id>|<tenant>，OFF→裸 bkcc__<id>）。
• 消费侧（feat: 支持surrealDB图关联查询 --story=133245352 #1282）后缀由运行时 TenantID 是否为空决定，且多租户下不 fallback 到裸 key。
• 两侧对齐是隐式契约：任一单独翻转（worker 开关 / uq 是否注入非空 TenantID）都会 route MISS → 图查询恒空。建议在上线文档明确"两个开关必须同步"，并逐环境核对。

⚠️ 建议补测试（当前缺口）

• 非多租户模式（EnableMultiTenantMode=false）下写裸 field 的路径 —— 零覆盖，恰是上面第 2 点的高发区。
• 降级路径（BKBase error → 跳过清理、保留旧路由）、未配置 URL → skip、重复 biz 报错路径。

提示（非阻塞，供知晓）

• 消费侧是 TTL 缓存、不订阅 channel：本 PR 的 publish 对 uq 消费侧不生效，binding 变更/删除后最长一个 TTL 才对查询生效——"实时下发"预期不成立，验收时按此预期。
• cluster_name 生产侧不校验（可能写空），消费侧空则回退默认集群；多集群环境下 binding 缺 storage.name 会静默落默认集群，建议知晓。
• 可观测：建议为 push 失败 / stale 清理条数加指标，与消费侧 binding lookup 指标对账，便于发现"空结果误清"类事故。

联合上线时序

先上 #1383（生产）、确认 Redis route 有数据后，再放量 #1282（消费）；反序（消费先行）会导致图查询恒空。

— 结论：核心正确，建议级 5 处；补齐第 1/2 点护栏与非多租户/降级测试后可合。

[tencentblueking-adm]

All committers have signed the CLA.