refactor(terminal): optimize log sanitization

[bulutmuf]

Summary

Replaced the 32-iteration loop in sanitizeForLog with a single-pass regex (/[\x00-\x1f\x7f]/g).

Impact

• Performance: Improves execution speed by reducing 33 replaceAll operations to a single replace call.
• Security: Maintains full CWE-117 compliance by effectively stripping control characters.
• Readability: Simplifies the codebase with standard regex patterns.

[greptile-apps]

Greptile Summary

Replaces the 33-iteration loop in sanitizeForLog (one replaceAll per C0 control character plus DEL) with a single /[\x00-\x1f\x7f]/g regex call. The character coverage is identical and stripAnsi is still invoked first, so semantics are fully preserved.

Confidence Score: 5/5

Safe to merge — equivalent behavior, no regressions.

The regex [\x00-\x1f\x7f] covers exactly the same 33 code points the old loop removed (0x00–0x1F plus 0x7F), stripAnsi is still applied first, and replace with the g flag is fully equivalent to chained replaceAll calls. No logic changes, no new edge cases.

No files require special attention.

_{Reviews (1): Last reviewed commit: "refactor(terminal): optimize log sanitiz..." | Re-trigger Greptile}

[altaywtf]

I ran a quick local microbenchmark to validate the performance claim in the PR body.

Environment: Node v24.14.0 on darwin arm64

Method:

• compared the old loop-based sanitizeForLog against the new regex version
• benchmarked the whole function (including the unchanged stripAnsi step)
• used warmup plus 7 timing rounds per case and reported the median
• verified the old and new implementations produced identical output for the benchmark inputs before timing

Results:

• plain-log (432 B, no control chars): old 1761.5 ns/op, new 615.1 ns/op → about 2.86x faster (-65.1%)
• ansi-and-controls (618 B, mixed ANSI + control chars): old 3281.4 ns/op, new 1407.7 ns/op → about 2.33x faster (-57.1%)
• control-heavy (1782 B, lots of control chars): old 9810.1 ns/op, new 5877.8 ns/op → about 1.67x faster (-40.1%)

So the claimed direction is real: the regex version was consistently faster in this local microbenchmark while preserving output for the tested cases.

Caveat: this is still a microbenchmark on representative strings, not an end-to-end production trace.

[altaywtf]

Merged in f039d80306.

This landed with the changelog follow-up and the earlier local benchmark note on-thread. Thanks for the tight refactor here, @bulutmuf — the behavior stayed equivalent and the regex path measured faster on the representative cases I checked.