feat(agentsight): add LLM latency metrics API

[yefuyou]

Summary

Backend/API phase for #2339.

Refs #2339

This PR adds backend collection and querying for LLM latency and throughput metrics in AgentSight.

What changed

• Add TTFT, TPS, TPOT, and E2E latency percentile metrics.
• Support time-range and agent_name filters.
• Capture the first observable meaningful output timestamp for HTTP/1 and HTTP/2 SSE responses.
• Preserve HTTP/2 SSE classification independently from meaningful-output observability.
  • [DONE]-only and metadata-only SSE responses remain streaming calls.
  • Such responses keep first_output_timestamp_ns as null when no meaningful output is observable.
• Persist raw timing facts and token counts in SQLite.
• Derive TTFT, TPS, TPOT, and E2E metrics at query time to avoid redundant derived values.
• Keep TTFT, TPS, and TPOT as null for non-SSE responses where first-token timing cannot be reliably observed.
• Continue calculating E2E latency for non-SSE responses.
• Keep first_output_timestamp_ns as null for compressed or otherwise unobservable HTTP/2 SSE responses.
• Add a backward-compatible schema migration without changing schema_version.
• Persist LLMCall first-output timing atomically with the corresponding SQLite INSERT/UPDATE.

API

Adds latency metric aggregation with:

• time-range filtering
• agent_name filtering
• p50 / p95 / p99 percentiles
• TTFT
• TPS
• TPOT
• E2E latency

Scope

This PR contains the backend/API phase only.

It does not include:

• UI changes
• eBPF changes
• compressed SSE first-output inference
• frontend integration

The Agent Panel UI will be handled separately.

Testing

• cargo fmt --all -- --check
• git diff --check
• cargo test --lib: 1483 passed / 0 failed / 1 ignored
• HTTP/1 and HTTP/2 first-output timestamp tests
• HTTP/2 DATA-frame timing propagation
• HTTP/2 SSE classification for [DONE]-only, metadata-only, and regular JSON responses
• HTTP/2 → Analyzer → GenAI → SQLite latency propagation
• streaming-call classification tests
• pending / idle-pending completion tests
• SQLite latency percentile tests
• latency API and time-range overflow tests

cargo test additionally encounters an existing doctest failure in
src/genai/helpers.rs. The same failure is reproducible on the current
upstream/main, and that file is not modified by this PR.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c0e2aaa07c

ℹ️ 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".

[yefuyou]

@chengshuyi The automated review raised two points that I’d like to confirm with you before making further changes:
TPS / TPOT semantics
The issue currently defines TPS as output_tokens / stream_duration and TPOT as stream_duration / output_tokens, with stream_duration measured from the first SSE token to stream end.
The reviewer pointed out that if this interval represents only post-first-token generation, using N - 1 tokens may better reflect inter-token throughput.
Could you confirm whether you prefer the issue definition as written, or the N - 1 interpretation?

PR size
This PR is already the backend/API half of the two-PR split we discussed in #2339, with the UI planned separately. The current diff is also test-heavy.
If you’d still prefer the backend/API part to be split further to stay under the 800-line guideline, I can do that; otherwise I’d prefer to keep the tested backend data path together.

I’ll wait for your preference on these two points before making further changes.

[chengshuyi]

LGTM. Clean design — derive metrics at query time, capture first-output timestamp atomically, good test coverage (~60% of diff).

A few minor nits (non-blocking):

1. TPS/TPOT convention: Keep N (total output_tokens) per the issue definition. Add a one-line comment in stats.rs noting this is by convention and the N vs N-1 difference is negligible for typical response lengths.

2. first_output_timestamp_ns() in http2.rs: The per-frame re-parse is O(frames²) worst case. In practice this is fine (first token arrives early → early return; no-output responses have tiny bodies). A one-line comment explaining this trade-off would help future readers.

3. stats.rs formatting: Missing blank line between get_latency_metrics closing brace and the next doc comment (/// One bucket in a token time-series query.).

4. PR size: Accepting the 998-line diff given it's test-heavy and the data path (capture → persist → query) needs to stay together for end-to-end testability.

Optional follow-ups (not blocking):

• Sync AGENTS.md API Endpoints table with /api/metrics/latency
• response_sse_event_count() doc: note that count includes non-JSON events like [DONE] (differs from response_sse_json_array().len())

[yefuyou]

Follow-up: the AgentSight CI lint failures from this PR and the non-blocking review nits are addressed in #2583.
No metric semantics or runtime behavior are changed.