Fix pipeline command accounting: flush trailing window + exact TotalOps

[fcostaoliveira]

Makes ftsb_redisearch report the correct command count and latency in pipeline mode. Follow-up to #114 (which made --pipeline >1 usable).

Note: an earlier revision of this branch claimed the fix was about the HDR histogram dropping RecordValue(0). A 7-way adversarial review disproved that — hdrhistogram-go v1.0.1 counts RecordValue(0), it does not drop it. The real op-drops were elsewhere; this PR fixes them and the description below is corrected.

Problems (all on the --pipeline N>1 path; pipeline=1 was already correct)

1. Trailing window never flushed → silent data loss. connectionProcessor buffered up to pipeline commands per slot but never flushed the leftover (< pipeline) at end of input, so the last rows % pipeline commands per batch were never sent to Redis or counted. E.g. --pipeline 3 over a 100-row input → only 99 executed and counted. Verified: dbsize dropped too.
2. TotalOps/overallOpsRate were histogram-derived and lossy. They came from hdrhistogram.TotalCount(), which (a) rejects any latency above the trackable cap (--max-latency-seconds, ~1.05s default — a cold FT.SEARCH, GC pause, or any i/o timeout), and (b) loses increments under concurrent unlocked RecordValue. Either silently undercounts ops.
3. Pipeline latency was measured from each command's buffer time, folding client-side queueing into the first command's latency.

Fix

• A — Split sendIfRequired into a guard + reusable flushPending, and flush every non-empty slot in connectionProcessor before finishing. No command is left unsent.
• B — Add an atomic totalOps counter (one increment per recorded command) and use it for TotalOps/overallOpsRate. The histograms now own percentiles only, where cap-clamping the tail is standard.
• C — Keep the send-time uniform pipeline latency (one batch round-trip per command — matches redis-benchmark), capture sendT after building the pipeline action, and reframe the 1µs floor honestly (a network round-trip is never 0µs; it is not a TotalOps fix).

Validation (E2E against redis)

TotalOps == dbsize == input count at every pipeline depth, was lossy before:

--pipeline	before	after
1	2000	2000
3	1980	2000
8	1920	2000
16	1920	2000
100	(lossy)	2000

Tests

• TestTotalOpsIsAtomicNotHistogramDerived — records an above-cap latency (rejected by the histogram) and asserts TotalOps still counts it (via the atomic counter).
• TestFTSBPipelineTailIsFlushedAndCounted — integration test: --pipeline 3 over the 100-row minimal.csv asserts TotalOps == 100 (pre-fix: 99). Runs in CI's Docker integration step.
• TestPipelineRecordsPerCommandTxAndDoesNotPanic — per-command Tx + equal/floored batch latency.
• Full cmd/... + benchmark_runner suites pass with -race.

Out of scope — filed as follow-ups

• Histogram RecordValue data race under -workers >1 (corrupts percentiles): see the tracking issue.
• Fix --pipeline >1 panic and pipelined byte/label accounting #114 reply capture unmarshals the full RESP reply inside the measured latency window, inflating FT.SEARCH latency: see the tracking issue.

[fcostaoliveira]

Follow-ups filed: #116 (histogram RecordValue race under -workers>1) and #117 (#114 reply-capture unmarshal inflating FT.SEARCH latency).

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[fcostaoliveira]

16-way adversarial review (Opus 4.8) done on the current HEAD — verdict: merge. Note for consumers: overallOpsRate/TotalOps become more correct (they now count tail/timeout/pipeline-tail ops the histogram previously dropped), so the value steps up at this merge for tail-heavy or pipelined runs — that's honest counting, not a throughput change. Follow-ups filed: #116 (histogram + timeseries races), #117 (reply-capture latency), and the new pipelined-error-count inflation issue.