[Priority: Med] [Ops] 增加可选 Prometheus metrics export 接口

[liujuanjuan1984]

🔍 发现的问题 / 原始需求描述

• 当前主干已经有一套轻量 metric log record，但仍停留在 debug 日志维度，运维系统无法直接抓取或聚合。
• 这导致容量观察、异常峰值判断、长流连接占用等信息只能靠日志二次加工，不利于长期作为 runtime 运行。
• 与本次审查建议相比，metrics export 和 trace context 应拆成两个 issue；本 issue 仅聚焦可选 metrics export。

🛠️ 详细实施方案

• 涉及文件：src/opencode_a2a/config.py
• 涉及文件：src/opencode_a2a/server/application.py
• 涉及文件：src/opencode_a2a/execution/executor.py
• 涉及文件：src/opencode_a2a/execution/stream_runtime.py
• 涉及文件：docs/guide.md
• 涉及文件：tests/server/test_app_behaviors.py
• 涉及文件：tests/execution/test_metrics.py
• 设计一个默认关闭的配置开关，例如 A2A_METRICS_ENABLED=true|false，在开启时暴露 /metrics 或等价 scrape endpoint。
• 保持现有 metric log 名称不变，只是在标准导出层复用这些信号，避免一次性重写现有回归面。
• 为长流和异步路径至少补齐：请求总数、进行中流数量、取消请求总数、上游并发拒绝次数。
• 核心逻辑 / 伪代码：

if settings.a2a_metrics_enabled:
    registry.counter("a2a_stream_requests_total").inc()
    registry.gauge("a2a_stream_active").add(+1/-1)
    expose GET /metrics
else:
    keep existing debug metric logs only

🧪 回归测试建议

• 增加 /metrics 开启/关闭两种配置下的接口测试。
• 确认现有 metric log 测试不回归。
• 运行 ./scripts/doctor.sh。

[liujuanjuan1984]

基于当前主干重新审查，这个 issue 我建议关闭，理由先记录如下：

• 当前项目定位仍然是 lightweight A2A runtime adapter，而不是完整运维平台。
• 主干已经有一套 lightweight metric log signals，可覆盖当前最基本的运行态观察需求；问题不是“完全没有观测能力”，而是“没有 Prometheus scrape export”。
• 如果当前明确不考虑接入 Prometheus/Grafana，那么 /metrics endpoint、registry、导出契约和对应测试面都会变成额外维护成本，而不是当前必需能力。
• 在这个前提下，继续保留本 issue 只会制造未来可能要做的噪音，不如明确关闭；若后续运维集成方向发生变化，再重新立项更干净。

因此我的建议是：

• 不在当前阶段引入 /metrics export surface
• 保留现有 lightweight metric logs 作为当前 runtime 的最小观测面
• 将本 issue 关闭；如果未来明确要接入 Prometheus/Grafana，再单独重开或新建 issue