search_files can substitute the wrong line when matched text contains :number: #186

What happened?

search_files can return the wrong source text when a matched line itself contains another :<number>: sequence.

For example, if line 1 is:

src/example.ts:42: build failed

the native grep tool correctly returns:

many.log:1: src/example.ts:42: build failed

but the Step-facing search_files result can become:

many.log:1: src/example.ts:42: UNRELATED_LINE_42

The adapter reparses rendered grep output with a greedy path:line:text regex, mistakes the later :42: for the real line number, then reloads line 42 from the file. Timestamp-shaped text such as 12:34: reproduces the same problem; if the false line number is past EOF, the visible result can become (no matches) while the details still report one match.

I reproduced this on clean main @ f113768 with the built-in tool profile and project-native Vitest, without external extensions.

Steps to reproduce

1. Create a 42-line file where line 1 is src/example.ts:42: build failed and line 42 is UNRELATED_LINE_42.
2. Run search_files for build failed on that file.
3. The native grep result contains the correct line-1 text.
4. The Step-facing result substitutes the contents of line 42.

Expected behavior

search_files should preserve the native match path, line number, and matched text without reinterpreting delimiter-like text inside the match.

Version

main @ f113768 / @step-harness/coding-agent 0.84.4