fix: the minute-level counter for req and resp are inaccurate

[lzf575]

This PR is for:

[lzf575]

@claude review下代码，使用中文

[claude]

Claude finished @lzf575's task in 30m 1s —— View job

---

任务进度

• 收集 PR 差异与上下文
• 阅读变更文件并检查逻辑正确性
• 整理中文 review 结论并更新 PR 评论

Review 结果

我看下来有 1 个需要处理的问题：

1. LRU 淘汰出来的 response 被合并进“当前日志”的统计里，会把时间桶和标签记错
   • 位置：@agent/src/common/l7_protocol_info.rs:291-303、@agent/src/common/l7_protocol_info.rs:420-441
   • 这里把 lru_evicted 的 Response 直接 sequential_merge 到当前日志的 L7PerfStats 里。后续发指标时，collect_l7_stats() 使用的是当前日志的 time_in_micros、endpoint、biz_type、is_reversed（见 @agent/src/flow_generator/flow_map.rs:1645-1685）。
   • 这样一来，如果被淘汰的 response 发生在上一分钟，而触发淘汰的当前日志落在下一分钟，这个 response 会被记到下一分钟；在 HTTP/2 / 多路复用场景下，还可能被记到错误的 endpoint 上。
   • 这意味着这个 PR 虽然补回了丢失的 resp 计数，但 minute-level req/resp 统计在跨分钟或多 endpoint 场景下仍然可能不准。
   • 建议不要把 lru_evicted response 合并到当前日志的 L7PerfStats；应该把它作为独立统计事件按 evicted.time 和自身标签发出，或者改造 flush 路径，保留被淘汰项的原始时间/标签再输出。
   • Fix this →

其他

• @agent/src/common/l7_protocol_log.rs:536-556 这里改成只在 flow end 补记 Response、避免对 Request 重复计数，这个方向我看下来是合理的。
• 这次是静态代码 review，未额外跑构建或测试。