ops(go): schedule capacity health checks

docs/ops/vehicle-ingest-runbook.md

@@ -76,6 +76,8 @@ curl -fsS http://127.0.0.1:20212/metrics | grep vehicle_history_kafka_lag
 curl -fsS http://127.0.0.1:20212/metrics | grep vehicle_history_batch
 curl -fsS http://127.0.0.1:20213/metrics | grep vehicle_stat_kafka_lag
 curl -fsS http://127.0.0.1:20200/metrics | grep vehicle_realtime_kafka_lag
+
+/opt/lingniu-go-native/current/capacity-check
 ```
 
 ## 健康基线
@@ -85,10 +87,20 @@ curl -fsS http://127.0.0.1:20200/metrics | grep vehicle_realtime_kafka_lag
 - 所有 `/readyz` 都返回 `status=ok`。
 - `vehicle_bridge_nats_consumer_ack_pending` 为 `0`。
 - history、stat、realtime 的 Kafka lag 为 `0` 或短时间小幅波动后归零。
+- `capacity-check` 返回 `status=ok` 且退出码为 `0`。
 - gateway 的帧计数持续增长。
 - bridge 的 Kafka write 和 NATS ack 计数同时增长。
 - writer 的成功计数增长，同时 Kafka lag 不持续扩大。
 
+定时容量巡检由 systemd timer 触发：
+
+```bash
+systemctl status lingniu-go-capacity-check.timer
+journalctl -u lingniu-go-capacity-check.service --since '10 minutes ago' --no-pager
+```
+
+如果 `lingniu-go-capacity-check.service` 失败，先看 journal JSON 里的 `findings`，再按对应层级处理。
+
 GB32960 和 JT/T 808 的活跃连接数受上游平台连接方式影响，不能直接等同于车辆数。突然归零或持续异常下降才是信号。
 
 ## 压测入口