fix: benchmark reporting — detect timeouts, fix comparisons

[strawgate]

Summary

• Timeout detection: BenchResult.timed_out flag set by wait_blackhole_done. Agents hitting the 120s timeout show TIMEOUT instead of "0 lines/sec".
• Exclude timed-out agents from comparisons: No more "filebeat is 1.2x faster than otelcol" when otelcol didn't finish.
• Runs column clarity: Shows 4203ms not 4203, and 120027ms(TIMEOUT) for timed-out runs.

Before (issue #322)

| otelcol | binary | 120027ms | 1ms | 0 lines/sec | 120027|120028|120027 |
> filebeat is 1.2x faster than otelcol

After

| otelcol | binary | **TIMEOUT** (120027ms) | 1ms | 0 lines (timed out) | 120027ms(TIMEOUT) | ... |

Comparisons only include agents that completed.

Test plan

• cargo clippy clean
• cargo fmt clean
• CI passes

Fixes #322

🤖 Generated with Claude Code

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: af7309d0-2b5e-47e0-86f1-ae5b0a28d62e

📥 Commits

Reviewing files that changed from the base of the PR and between 885922a and d830e9a.

📒 Files selected for processing (3)

• crates/logfwd-competitive-bench/src/main.rs
• crates/logfwd-competitive-bench/src/runner.rs
• crates/logfwd-competitive-bench/src/summarize.rs

---

Walkthrough

This PR adds timeout detection and tracking to the competitive benchmarking framework. A new timed_out boolean field is added to BenchResult to indicate when a benchmark run exceeds its configured timeout. The timeout status is determined by wait_blackhole_done() which now returns a tuple containing both lines processed and a timeout flag. All runner functions are updated to destructure and propagate this value to the result struct. Summarization logic then uses this information to annotate timed-out runs in output and exclude them from performance comparisons.

Possibly related PRs

• Benchmark dashboard v2: matrix CI, runtime sampling, three-section site #301: Extended BenchResult with additional run metadata (iteration/samples and sampling logic) in the same benchmarking infrastructure
• fix: Include bench dashboard in docs site deployment #310: Modified runner and summarize logic including BenchResult field additions and summarize output formatting
• feat: Benchmark reorg — fix failures, dual mode, github-action-benchmark #66: Added mode field to BenchResult struct, establishing the pattern for extending benchmark result tracking

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

The timeout check runs before checking whether the expected line count has been reached, which can misclassify successful runs as timed out near the boundary.

Concrete case: if lines reaches expected just before 120s, the next loop iteration may start slightly after 120s and return (lines, true) immediately, even though the run actually completed.

Consider re-checking lines >= expected in the timeout branch (or reading stats first each loop) before returning timed_out = true.