fix: print search stats after matches - #146

This PR fixes --stats output ordering so that human-readable stats are emitted after buffered match output when stdout/stderr are combined (aligning behavior with ripgrep), and adds regression tests to prevent the ordering from regressing.

Changes:

• Flush stdout match output before printing human-readable --stats lines in brute-force, local-index, and server search paths.
• Defer local-index “Query plan” stats until after matches are written.
• Add regression tests validating match output precedes stats when stdout and stderr are merged.

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Lite

Suppressed comments (2)

Previously missed (1) — in code that hasn't changed since the last review.

tgrep-cli/tests/ripgrep_compat.rs:187

• The test reads merged_path while the parent process still holds write handles (stdout/merged) open. On some platforms this can cause sharing/flush issues and makes the test less robust. Drop the write handles before reading the file contents.

This issue also appears on line 222 of the same file.

tgrep-cli/tests/ripgrep_compat.rs:224

• As above, drop the merged-output write handles before reading the file so the test is robust across platforms and filesystems.

    assert!(status.success());

    let output = fs::read_to_string(merged_path).unwrap();

• Files reviewed: 2/2 changed files
• Comments generated: 0 new
• Review effort level: Lite

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

tgrep-cli/src/search.rs:1327

• The --stats message for a single-file brute-force search says "(1 files)", which is grammatically incorrect and user-visible in --stats output.

• Files reviewed: 2/2 changed files
• Comments generated: 0 new
• Review effort level: Lite

Suppressed comments (4)

Previously missed (1) — in code that hasn't changed since the last review.

tgrep-cli/src/search.rs:1088

• writer.flush()? here is only needed to preserve stdout/stderr ordering, but it can return BrokenPipe when stdout is closed early (e.g., tgrep ... | head). Using ? will abort before writing the --stats summary to stderr, which is surprising since stderr is still writable. Consider ignoring BrokenPipe for this pre-stats flush and only erroring on other flush failures.

This issue also appears in the following locations of the same file:

• line 1204
• line 1324
• line 1369

tgrep-cli/src/search.rs:1204

• This pre-stats writer.flush()? is intended for output ordering, but ? will propagate BrokenPipe and prevent the --stats lines from being printed to stderr when stdout is closed early by a downstream consumer. Consider ignoring BrokenPipe for this flush (only for ordering) so stats can still be emitted.

        writer.flush()?;

tgrep-cli/src/search.rs:1324

• writer.flush()? before printing stats can return BrokenPipe when stdout is closed early (common in pipelines). Using ? here will skip the stats line entirely even though it is written to stderr. Consider ignoring BrokenPipe for this ordering flush so --stats remains observable.

            writer.flush()?;

tgrep-cli/src/search.rs:1369

• Same concern as the other stats flush sites: propagating BrokenPipe here can prevent --stats from being printed to stderr when stdout is closed early. If the goal is just ordering, consider ignoring BrokenPipe for this flush.

        writer.flush()?;

• Files reviewed: 2/2 changed files
• Comments generated: 0 new
• Review effort level: Lite

• Files reviewed: 2/2 changed files
• Comments generated: 0 new
• Review effort level: Lite