find_files drops bracket-prefixed paths in narrowed searches #185

What happened?

find_files can silently drop valid matches when the returned relative path starts with [ or WARNING:.

A common case is a narrowed search inside a Next.js routes directory. With routes/[id]/page.tsx present, find_files with path: "routes" returns (no matches), even though the native find backend returns [id]/page.tsx correctly. The same reproduces with [...slug] and [[...slug]].

The Step adapter currently strips every native output line starting with [ or WARNING:, so valid paths are treated as notices.

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 routes/[id]/page.tsx.
2. Run find_files with:

   { "pattern": "*.tsx", "path": "routes" }

3. The native find tool returns [id]/page.tsx.
4. The Step-facing find_files result is (no matches), with matchedFiles: 0 and returnedFiles: 0.

Expected behavior

Valid file paths should not be removed because their relative path happens to start with text used by native notices.

Version

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