feat(pymsg): RpcClient 新增 retry_on_refused 阻塞等待模式，解决微服务启动顺序依赖

pymsg 客户端:
- MsgClient.call() 新增 retry_on_refused/retry_interval 参数
  - retry_on_refused=True 时，ConnectionRefusedError 不抛出，按 retry_interval(默认1s)阻塞重试
  - 重试期间每5秒向 stderr 打印等待提示，避免日志刷屏
  - 仅对 ConnectionRefusedError 重试；TimeoutError/ConnectionError/RpcError 仍立即抛出
  - 默认 retry_on_refused=False，完全向后兼容
- RpcClient 构造函数新增同名关键字参数，call() 支持单次调用覆盖
- 新增 time 模块导入
- 更新 README 文档（新增"启动等待模式"章节和参数表）

各服务（db/dnfs/static）:
- _fetch_from_confs() 改用 retry_on_refused=True，移除手动 ConnectionRefusedError 捕获和 sys.exit
- 保留 RpcError（如配置文件不存在）的友好错误处理和 sys.exit(1)
- 启动时不再因 confs 未就绪而退出：pymsg 自动阻塞等待 confs 启动后自动连接成功
- 启动顺序从"刚性要求 confs 先启动"变为"不严格要求启动顺序"
- log_client 保持默认 retry_on_refused=False，后台线程不阻塞（fail-safe 丢弃日志）
- 更新各服务 README 和 confs README 的启动顺序描述

测试验证:
- 基本 call() 正常工作
- retry_on_refused=False 连接拒绝立即抛 ConnectionRefusedError
- retry_on_refused=True 阻塞等待（延迟1.5s启动服务后成功连接，重试日志正常输出）

db/README.md

@@ -72,13 +72,13 @@ confs 自身的连接地址不通过 confs 获取（避免循环依赖），通
 | `CONFS_HOST` | confs 服务地址（引导配置） | — |
 | `CONFS_PORT` | confs 服务端口（引导配置） | — |
 
-### 启动顺序要求
+### 启动顺序
 
-**confs 必须先于 db 启动**（启动顺序调整为：confs → db → ai_review/...）。若 confs 不可用：
-- db 打印致命错误到 stderr（包含 confs 地址和具体错误原因），以 exit code 1 终止
-- 不会静默使用默认值启动
-- 配置完整性校验：若 db.ini 中缺少必需的 section/key 且无对应环境变量覆盖，同样报错退出
-- 启动成功时控制台打印：`配置来源: confs 统一配置服务 (db.ini @ host:port)`
+db 通过 pymsg `retry_on_refused=True` 自动阻塞等待 confs 就绪，**不严格要求启动顺序**：
+- confs 先启动 → db 立即拉取配置，正常启动
+- db 先启动 → pymsg 自动重试（每秒一次，每 5 秒打印等待提示），confs 启动后自动连接成功
+- 配置完整性校验：若 db.ini 中缺少必需的 section/key 且无对应环境变量覆盖，仍然报错退出
+- 启动成功时控制台打印：`配置来源: confs (db.ini @ host:port)`
 
 > 独立运维工具 `db_tools.py`（backup/export/import/vacuum 等）仍直接读 `DATABASE_URL` 环境变量，不依赖 confs 服务就绪。
 > Docker 环境通过 `docker-entrypoint.sh` 传入环境变量（见 [Dockerfile](Dockerfile)），需确保 `CONFS_HOST`/`CONFS_PORT` 指向 confs 服务地址。